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Appendix  A 

Gist  specification  of  package  router 


In  this  appendix,  we  present  the  format  Gist  specification  of  the  package  router  problem.  The 
English  description  is  given  in  section  3.1 ,  page  38.  An  overview  of  the  specification  is  given 
in  Chapter  4.  The  original  router  specification  is  due  to  Feather  and  London  [London  & 
Feather  82];  the  version  here  incorporates  some  minor  improvements. 


Key  to  font  conventions  and  special  symbols  used  in  Gist 

symbol  meaning  example 

|  of  type  obj  |  t  •  object  obi  of  type  t 

j|  such  that  ( an  integer  ||  ( integer  >  3 ) )  -  an  integer  greater  than  3 

_  may  be  used  to  build  names,  like  this.name 

concatenates  a  type  name  with  a  suffix  to  form  a  variable  name,  e.g .  integer,  i 
Variables  with  distinct  suffices  denote  distinct  objects. 


fonts 

underlined 

SMALL  CAPITALS 
lower  case  italics 
UPPER  CASE  BOLDFACE 
Mixed  Case  Boldface 


meaning  example 

keyword  beoin.  definition,  if 

type  name  integer 

variable  x 

action,  demon,  relation  and  constraint  names  SET.SWITCH 
attribute  names  Destination 


Package  Router  Specification  in  Gist 


The  network  hardware 

tvoe  location!)  supertvpe  gf 
<  SOURCE(aource_outlet  |  pipe); 

Oat  comment  •  the  above  line  defines  source  to  be  a  type  with  one  attribute,  aource.outlet,  and 
only  objects  of  type  wet  may  serve  as  such  attributes,  end  comment 
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3 


pipe(connection_to_switch_or_bin  |  (switch  union  bin)  ); 

Sw>TCH(switch.outlet  |  pipe  :2,  s  wit  ch.setting  |  pipe) 
where  always  required 

*w/fch:switch_setting  ■  switch:*w\ich  outlet  end: 

BIN() 

>; 


Sets  comment  •  of  the  above  types  and  attribute,  only  the  SWITCH_SETTING  attribute  of  switch  it 
dynamic  in  this  specification,  the  others  remain  fixed  throughout,  (ng  comment 

Gist  comment  •  by  default,  attributes  (e.g.  80URCE.0UTLET)  of  types  («.g.  source)  are  functional 
•  (e  g  there  is  one  and  only  one  pipe  serving  as  the  SWITCH_SETTING  attribute  of  the  source).  The 
default  may  be  overridden,  as  occurs  in  the  SWITCH.OUTLET  attribute  of  switch  •  there  the  ":2" 
indicates  that  each  switch  has  exactly  2  pipes  serving  as  Ms  SWITCH.OUTLET  attribute,  end 
comment 

always  prohibited  MORE  THAN  ONE  SOURCE 
exists  source.  1,  source.2\ 

Gist  comment  ■  constraints  may  be  stated  as  predicates  following  either  always  reouired  (in  which 
case  the  predicate  must  always  evaluate  to  true),  or  always  prohibited  (in  which  case  the  predicate 
must  never  evaluate  to  true).  The  usual  logical  connectives,  quantification,  etc.  may  be  used  in  Gist 
predicates.  Distinct  suffixes  on  type  names  after  exists  have  the  special  meaning  of  denoting  distinct 
objects.  and  comment 

always  required  PIPE  EMERGES  FROM  UNIQUE  SWITCH  OR  SOURCE 
tot  ail  p/pe|| 

l  exists  unique  switch  or  source  |  (SWITCH  union  SOURCE)  || 

( pipe  «  swiic h_or_source\ s w It c h_ou t let  fit 
pipe  ■  swi'fch_or_sourcr.sourc9_outl9t)); 

Gist  comment  -  the  values  of  attributes  can  be  retrieved'in  the  following  manner:  if  obi  Is  an  object  of 
type  t,  where  type  t  has  an  attribute  ATT,  then  ob/  ATT  denotes  any  object  serving  as  ob/'s  ATT 
attribute,  end  comment 

always  required  UNIQUE  PIPE  LEADS  INTO  SWITCH  OR  BIN 
|q[  All  switch  _orJ>in  |  (switch  union  bin)  || 

( exists  unique  pipe  j| 

( p/pe:eonn9Ctlon_to_swlteh_or_bln  ■  switch jor_bin ) ) ; 
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ISifiliflQ  LOC  ATI  0  N_ON_RO  UTE_T  0_BI  U(LOCATION,BIN) 
definition 

£fi£fi  LOCATION  gf 
BIN  »>  LOCATION  •  BIN-, 

pipe  ■  >  LOCATION_ON_ROUTE_TO_BIN(i_OCA770A/:connection_to_switch_or_bin,8/N); 
SWITCH  »>  LOCATION_ON_ROUTE_TO_BIN(LOCAr/OA/:switch_outiet,a/W);’ 

SOURCE  «>  LOCATION_ON_ROUTE_TO_BIN(LOCA770A/:aource_outlet,B/N); 
end  case: 

Development  comment  •  mapped  at  «tec  5.4  end  comment 


Spec  comment  •  this  relation  it  defined  to  hold  between  a  location  and  bin  if  and  only  tt  the  location 
Net  on  route  to  the  bin,  i.e.  the  location  ia  the  bin,  or  the  location  ia  a  pipe  connected  to  a  location 
leading  to  the  bin  (a  recursive  definition),  or  a  twitch  either  of  the  outlets  of  which  leads  to  the  bin.  or  a 
source  whose  outlet  leads  to  the  bin.  comment 


Gist  comment  -  the  predicate  of  a  defined  relation  denotes  those  tuples  of  objects  participating  in 
that  relation.  For  any  tuple  of  objects  of  the  appropriate  types,  that  tuple  (in  the  above  relation,  a 
2-tuple  of  LOCATION  and  BIN)  is  in  the  defined  relation  If  and  only  if  the  defining  predicate  equals  true 
for  those  objects,  end  comment 

always  required  SOURCE_ON_ROUTE_TO_ALLJBINS 
ffi£ fltl  bin  ||  LOCATION  ON  ROUTE  TO  BINfthe  source, bin) ; 


Packages  -  the  objects  moving  through  the  network 


ftps  PACKAGE(located_at  |  location,  destination  |  bin)  ; 

relation  MISROUTED(PACKAGE) 

definition 

-  LOCATiON_ON_ROUTE_TO_BIN(PACKAG£:located_at,  PACKAGE  destination)  fl£ 
S WITCH_SET_WRONG_FOR_P AC K AGE(PA CKAGE :loc ated  at , PACKAGE) ; 


Development  comment  •  mapped  at  step  5.5  Ed  comment 


Spec  comment  •  a  package  ia  miarouted  If  it  is  at  a  location  not  on  route  to  its  destination,  or  in  a 
switch  sat  the  wrong  way.  and  comment 
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Implementable  Portion 


Spec  comment  -  the  portion  over  which  we  have  control,  and  ere  to  implement.  end  comment 
aoent  package JtOUTE  RO  where 

relation  PACK  AGES.EVER_AT_SOURCE(PACKAGf_S£0  |  sequence  flf  package) 
definition  PACKAGE_SEO  • 

({ package  ||  (pac*age:located_at  *  the  source)  asof  evert 
ordered  temporally  bv  start  (oackaoeriocated  at  ■  the  source)): 

Development  comment  •  mapped  at  eteo  1.10  and  comment 


Soec  comment  -  the  sequence  of  packages  aver  to  have  been  located  at  the  source,  in  the  order  in 
which  they  were  there,  end  comment 


The  source  station 
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demon  RELEASE  PACKAGE  INTO  NETWORKfoackaoe.new) 
triooer  package. new: located  at  ■  the  source 
response 
begin 

jf  (lbfi  package. previous  ||  ( package. previous  immediately  <  package. new 

Ml  PACKAGES_EVER_AT_SOURCE(*) ) 
^destination  *  package,  ne  widest  ination 
then  WAITfl : 


Development  comment  •  part  of  final  implementation  and  comment 


Spec  comment  •  must  delay  release  of  the  new  package  unless  the  immediately  preceding  package 
was  destined  for  the  same  bin.  end  comment 

update  ilocated.at  gf  package. new  &  (the  source):source_outlet 

sod; 


Gist  comment  -  a  demon  is  a  date-triggered  process.  Whenever  a  state  change  takes  place  in  which 
the  value  of  demon's  trigger  predicate  changes  from  false  to  true,  the  demon  is  triggered,  and  performs 
Its  response 

The  use  of  a  relation  with  a  filling  one  of  its  positions  denotes  any  object  that  could  fill  that  position. 
Thus  R(. tor  relation  R  is  equivalent  to  fl QObj  H  R {...obi,..)  gnjj  comment 


The  switches 


relation  SWITCH  _IS_EMPTY(sw/fch) 
definition  ~  exists  package  II  oackaoeilocated  at  «  switch-. 


Development  comment  •  unfolded  at  step  6.10  aofi  comment 
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demon  SET_SWITCH(sw7fcrt) 
trigger  RANDOMQ 

aSBBDSfi 

begin 

require  SWITCHJS_EMPTY(s*/fc/j); 
update  .‘switch.setting  gf  switch  tg  switch: switch.outlet 
end: 

Development  comment  •  mapped  at  step  6.1  and  comment 

Spec  comment  •  the  non-determinism  of  when  end  which  wsy  to  set  switches  is  constrained  by  the 
always  prohibited  that  follows  shortly:  jgtg  comment 

relation  PACKAGES_DUE_AT_SWITCH(PACKAGfSJ>U£  |  sequence  gf  PACKAGE,  SWITCH) 
definition 

PACKAGES_DUE  * 

{  a  package  || 

LOCATION  ON  ROUTE  TO  BiN(SW/7CW.oflekaoe:destination)  and 
~  ((pac/<age:located_at  «  SWITCH)  asof  ever)  and 
-  MISROUTED(pac*age) 

1  ordered  wrt  start  (package located  at  «  the  source) 

Development  comment  -  mapped  at  step  6.1  end  comment 

Spec  comment  -  packages  due  at  a  switch  are  those  packages  for  whom  (i)  the  switch  lies  on  their 
route  to  their  destinations,  (ii)  they  have  not  already  reached  the  switch,  and  (iii)  they  are  not  misrouted. 

They  are  ordered  by  the  order  in  which  they  were  at  the  source.  Eli  comment 

relation  SWITCH_SET_WRONG_FOR_PACKAGE(SIV/7CW,  PACKAGE) 

definition 

LOCATION  ON  ROUTE  TO  B\N(S  WITCH. PACK  AG  E:dm*tinat\on)  and 
-  LOCATION_ON_ROUTE_TO_BIN(SW/7CH:swltch_ssttfnfl,PACKAGf:d0Stination); 

Development  comment  •  mapped  at  step  5.8  gofil  comment 

Spec  comment  -  A  switch  is  set  wrong  for  a  package  if  the  switch  lies  on  the  route  to  that  package's 
destination,  but  the  switch  is  set  the  wrong  way  finfl  comment 


A  Gist  specification  of  package  router 


PAGE  195 


always  prohibited  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
exists  package,  switch  || 

( package:\ocated_a\  «  switch 
and 

SWITCH_SET_WRONG_FOR_PACKAGE(sw/fcft,pac*age) 

and 

(( package  -  firstfPACKAGES  DUE  AT  SWITCH C switch))  and 
SWITCH  _IS_EMPTY(sw/fc/7) )  flSfif  SYSE ) 

); 


Development  comment  •  mtppad  at  step  4.1  end  comment 


Soec  comment  •  must  never  reach  a  state  in  which  a  package  is  in  a  wrongly  set  switch,  If  there  has 
been  an  opportunity  to  set  the  switch  correctly  for  that  package,  i.e.  at  some  time  that  package  was  the 
'  r  »t  of  those  due  at  the  switch  and  the  switch  was  empty.  £&  comment 


Arrival  of  misrouted  package 


demon  MISROUTED  PACKAGE  REACHED  BlN(Dackaae,bin.reached,bin.intended) 
trigger  package:located_at  *  bin. reached  and  oaeAaoe.destination  ■  bin.intended 
response  MISROUTED_ARRIVAL[  bin. reached,  bin.intended ) ; 


Development  comment  •  mapped  at  step  6.13  god  comment 


action  MISROUTED_ARRIVAL[  bin. reached,  bin.intended  ] 


Development  comment  •  part  of  implementation  end  comment 


The  environment 
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aoent  environment)  where 


Arrival  of  packages  at  source 


demon  CREATE.PACK AGE() 
triooer  RANDOM() 
response 

create  oackaae.new  II  (  package. ne widest Inatlon  *  ^  bin  and 
package. new: iocated.at  «  the  source  ) : 

Spec  comment  •  for  the  purposes  of  defining  the  environment  in  which  the  package  router  is  to 
operate,  packages  arrive  at  random  intervals  at  the  source  with  random  destinations,  subject  to  the 
following  constraint,  end  comment 

always  prohibited  MULTIPLE  PACKAGES  AT  SOURCE 
exists  package.  1 ,  package.2  || 

package.  7:located_at  «  the  source  and  oac/raoe.2:located  at  *  the  source  : 

Movement  of  packages  through  network 


relation  MOVEMENT_CONNECTION(LOCAT/OW.  7,  LOCATION .2) 
definition 

( fiflSfi  LOCATION.  1  gf 

pipe  * >  LOCATION.  7:connection_to_switch_or_bfn; 
switch  m >  LOCATION.  7:switch_setting 
end  case )  -  LOCATIONS ; 


demon  MOVE  PACKAGEtoackaoe) 

triooer  3  location. next  ||  MOVEMENT_CONNECTION(paeaftpe:LOCATED_AT,  location. next) 
response 

update  :located_at  gf  package  la  MOVEMENT_CONNECTION(pacfcage:located_at,  *); 

Spec  comment  -  this  demon  models  the  unpredictable  movement  of  packages  through  the 
network.lt  triggers  when  a  package  has  some  place  to  move  to  (all  cases  except  when  in  a  bin)  and  at 
some  arbitrary  time  in  the  future  moves  it  there,  end  comment 
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always  prohibited  PACKAGES  OVERTAKING  ONE  ANOTHER 
exists  package.  1,  package. 2,  location 
II  start  ( package. located  at  ■  location  )  earlier  than 
start l package. 2Aocaied  at  ■  location)  &Qd 

finish  ( pack  age. 2: located_at  -  location )  earlier  than 
finish  ( package.  1  :located_at  *  location ) ; 

Spec  comment  ■  we  are  assured  that  packages  do  not  overtake  one  another  while  they  are  moved 
through  the  network:  a  package  which  enters  a  location  (switch,  pipe,  source)  eralier  than  another 
does  not  exit  later,  end  comment 


action  WAITH ; 


Observable  environment 


Spec  comment  •  portions  of  environment  to  be  used  to  describe  observable  information  available  to 
implementor,  end  comment 


type  SENSOR0  supertype  flf  <  switchQ ;  bin()  > ; 


demon  PACKAGE  ENTERING  SENSOR(oackape,sensor) 
triooer  pacfcage:located_at  *  sensor 
response  null : 

demon  PACKAGE  LEAVING  SENS  OR  (package  .sensor) 
triooer  -  package: located.at  *  sensor 
response  null 
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Implementation  Specification 


Saec  comment  -  this  section  is  intended  to  capture  the  requirements  placed  on  an  implementor  of 
the  package  router  agent,  end  comment 

implement  package.router 
observing 

attributes 

sou  rce.outlet, 

connection  _to_switch_or_bin, 
switch.outlet, 

pac*ape:destination  when  oackaoeilocated  at  ■  the  source. 
oackaoe:located  at  when  oacAaoe:located  at  «  the  source  : 

events 

PACKAGE_ENTERING_SENSOR($, sensor), 

PACK  AGE_LE  A  VING_SENSOR($, sensor) ; 

effecting 

attributes 

switch.setting, 

packape:located_at  whfin  package:located_at  *  source  ; 


excelling 

events 

Ml  S  ROUTED.  A  R  Rl  V  A  L  (b/n.  reached, bin.  intended ) 
WAITD; 


end  implement: 


B  Development  Goal-Structure 
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Appendix  B 

Development  Goal-Structure 

In  this  appendix,  we  explicate  the  implicit  goal  structure  of  the  router  development  of 
appendix  C  and  further,  provide  a  broad  outline  of  that  development.  The  sectioning  of  the 
appendix  follows  that  of  appendix  C.  Each  step  takes  the  following  form: 

Level  StepNum  Goal  <arguments> 

Method 

The  level,  a  positivie  interger,  represents  the  goal  nesting  level.  This  is  also  provided  visually 
by  indentation.  Goals  at  level  0,  i.e.  goals  posted  by  the  user,  have  no  level  printed.  All  goals 
posted  by  the  user  are  underlined.  A  goal's  <arguments>  are  generally  printed  in  abbreviated 
form  so  as  to  fit  on  a  single  line.  The  method  printed  below  the  goal  is  the  one  chosen  in  the 
development. 


a 


in 


V 

I 
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B.l.  Remove  PACKAGES.EVER.AT.SOURCE 


1 . 1  fiamova  mu  from  «oec 


RemoveRelation 


1  1.2  Ramona  reference  to  packages.ever.at.aource  (pats)  from  tpac 


2  1.3  Isoiata  derived  object 


3  1.4  Giobaiaa  derived  object 


MagaMova 


FoldGanaricIntoRalation 


GlobaiixeDerivedObject 


1.5  (try)  Raformulata  p.naw  as  global 


RaformulataLocalAaLaat 


1.6  Raformuiate  p.naw  aa  last(peaaf)) 


1.7  Manual  manual-raplaca(p.naw  laat(peas)) 


manual  atap 


2  1.8  Malnialnincramantally  pra vioua.package 


3  1 .9  Fiatian  praviousjMckage 


4  1.10  Map 


ScatterMaintenanceForDerivedRelation 


Flattan 


MaintainOarivadRalation 


1.11  Malntalnlneramantally  pea* 


IntroducaSeqMaintenanea  Demon 


O  -.'A' 
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T* 

is 


K  $ 


U  ft 


i 


>2 
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p 

P  a 
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ft 
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1  1.12  Remove  reference  pets  from  spec 

Posit  ionalMegaMove 

2  1 .13  Reformulate  derived -object  as  positional  retrieval 

Refo  rmulateDe  rivedObject 

3  1.14  Reformulate  relative  retrieval  as  equivalence  relation 

ReformulateRelativeRetrievalAsLaet 

4  1.15  Equivalence  last(peas@p)  and  p 

Anchor2 

5  1.16  Reformulate  last(peas@p)  as  p 

Refo  rmu  late  AaOb  ject 

2  1.17  Isolate  last(peas) 

FoldGene  ric  I  ntoRelat  ion 
2  1.18  Maintainlncrementally  last  .package 

ScatterMaintenanceForDerivedRelation 

1  1.18  Remove  reference  peas  from  spec 

Remo  veByOb  jectizi  ngContext 

2  1 .20  Reformulate  laat(peas®  p)  as  object 

Refo  rmulateAaOb  ject 

1  1.21  Remove  update  peas  from  spec 

RemoveUnusedAction 

2  1 .22  Show  update  unnoticed 

ShowDysteleologlcal 


I 
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B.2.  Remove  PREVIOUS.PACKAGE 


2.1  flamoy  previous  necks  oe 


RemovaRelation 


1  2.2  Remove  reference  previousj>ackage  from  apac 


ReplaceRefWithValue 


2  2.3  Snow  valua  known  of  previous .package 


ShowUpdateGivesValue 


2  2.4  Snow  last  .package  atm  holds  at  conditional 


ShowNawValuaSUIIValid 


3  2.5  Show  Iasi .package  doaan't  change 


MovelnterveningUpdste 


4  2.6  ComputoSoQuontialiy  update  of  last  .package  attar  conditional 


MoveOutOf  Atomic 


2.7  Unfold  atomic 


UnfoldAtomic 


2.6  (raposted)  ComputtStQuontiaiiy  update  of  last.packaga 
attar  conditional 


Consol  idataToMakaSaquantial 

2.0  Contolidati  notice  new  oackaoa  at  source  and 
reteaae.package.into.network 


Marge  Damons 


2.10£qu/va/ence  declaration  lists 


EquivalancaCompoundSt  ructu  res 


R«mov«Unu**dAe»ion 


.Mi:  VAA  BfrV  ILV  MV*.  »J3 


B.3  Remove  LAST  PACKAGE 
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B.4.  Map  DID.NOT  SET  SWITCH.WHEN  HAD.CHANCE 


4.1  Msg  did.not.set.ewitch.when.had.ehBnce 


1  4.2  Show  body  implies  O 


MapConst  raint  AsOsmon 


Conjunct  ImpliaaCon  junct  A  r 


1  4.3  Map  set.switch.wben.have.chance  (sswhc) 


MapByConaolidation 


2  4.4  Consolidate  sswhc  and  aetswitch 


3  4.5  Equivalence  two  triggers 


Merge  Demons 


Anchor2 


4  4.6  Reformulate  random  as  specific 


SpecializeRandom 


4.7  Mao  require  -P  from  ThisEvent  until  EverMore 


CasifyPos  Constraint 


1  4.8  Casify  require  -P  from  ThisEvent  until  EverMore 


Css  if  y  F  rom  U  nt  ilEve  r Const  raint 


1  4.9  Map  require  -P  at  ThisEvent 


T  rigge  rlmpliesConst  raint 


1  4. 10  Map  require  -P  after  ThisEvent 


CasifyPos  Const  raint 


2  4.11  Casify  require  ~P  after  ThisEvent 
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CasifyAroundEvent 

2  4.12  Map  require  ~P  alter  ThiaEvent  until  E 


2  4.13  Map  -P  during  E 


NotXUntilX 


CasifyPoaConetraint 


3  4.14  Casify  require  -P  during  E 


Paatlnduction 

3  4.15  Map  require  -P  at  last  update  switch.setting 

Mo  veConat  raintTo  Action 

3  4.16  Map  require  -(start  -P)  between  last  update.  E 

ShowNoChange 

4  4.17  Show  -(start  -P)  between  last  update,  E 


Z 

4.16  Mao  update  of  switch.aetting  where  P 

ComputeNew  Value 

4.19  Unfold  switch.set.wrong.forjaackage  at  set.switch 


Development  Goal-Structure 


ComputeNew  Value 


8.4  Map  DID  NOT.SET  SWITCH.WHEN.HAD.CHANCE 


B.5.  Map  PACKAGES.DUE.AT.SWITCH 


5.1  Mao  packages.due.at  switch  (pdas) 


1  5.2  Maintain Incrementally  pdas 


2  5.3  Flatten  pdas 


MaintainDerivedReiation 


ScatterMaintananceForDarivadRalation 


Flatten 


3  5.4  Map  location_on.route.to.bin 


StoreExplicitly 


3  5.5  Map  misrouted 


Unfold  OerivadRalation 


4  5  6  Untold  misrouted  at  pdas 


2  5.7  Flatten  pdas 


ScattarComputationOfDarivadRalation 


Flattan 


3  5.8  Map  switch  set. wrong.for.package 


UnfoldDarivadRalation 


4  5.9  Untold  switch.eet.wrong.for.package 


ScattarComputationOfDarivadRalation 


1  5.10  Purity  loop  in  create.package 


Purify  Damon 


2  511  Remove  loop  from  create  .package 
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Remove  From  Demon 

3  5.1 2  Globalize  loop  in  create.package 


GlobalizeAction 


4  513  Untold  atomic 


UnfoldAtomic 

1  5.14  PurHy  conditional  in  move.pack.age 

Purify  Damon 

2  5.15  Remove  conditional  in  move.package 

RamovaFromDemon 

3  5 16  Globalize  conditional  in  move.package 

GlobalizeAction 

4  5.17  Untold  atomic 

UnfoldAtomic 


5.18  easily  package.leaving.sensor 


5.19  Casifv  package.entering.iensor 


CaaifySuparT rigger 
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B.5  Map  PACKAQES.DUE.AT.SWITCH 


B.6.  Map  Demons 


6.1  Mao  set.switch 


1  6.2  Casify  set.switch 


CasifyDemon 


CesifyConjunctiveT  rigger 


1  6.3  Map  set.switch. when.bubble.package  (sswbp) 


Unfold  Demon 


2  6.4  Unfold  sswbp  at  release.package.into.network 


ScatterComputationOf  Demon 


3  6.5  Factor  update  of  packages  due  at.awltch 


1  6.6  Map  set.switch.on.exit 


Facto  rDBMaintenancelnto  Act  ion 


MapByConsolidation 


2  6.7  Consolidata  set.switch.on.exit  and  package.leaving.switch 


3  6.6  Eouivalanca  triggers 


Merge  Damons 


Anchorl 


4  6.6  Ratormulata  switch.is.empty  as  expression 


ReformulateDe  rived  Relation 


6.10  Unfold  switch.is.empty  in  trigger 
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ScatterComputationOfDerivedRelation 


6.11  (reposted)  Ratormulata  existential  as  universal 
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Ref  ormulateExiatentialTrigge  r 
6  6.12  Equivalence  two  declarations 

Anchor2 

6.13  Mao  misrouted  package  reached  bin 

CasifyDemon 

1  6.14  Caslly  misrouted .package.reached.bin 

CasityConjunctiveT  rigger 

1  6.15  Map  misrouted jjackaoe.located.at.bin 

MapByConsolidation 

2  6  16  Consolidate  misrouted .package.located.at.bin  and  package.entering.bin 

Merge  Demons 

3  6. 17  Equivalence  declaration  lists 

EquivalenceCompoundStructures 

4  618  Equivalence  bm.reached  and  bin 

Anchorl 

4  6  IB  (reposted)  Equivalence  declaration  lists 

AddNewVar 

1  6.20  Map  rmsroutad.packaee.destination.aet 

Untold  Demon 

2  6.21  Untold  misrouMd.packaee.destination.set 


Scatte  rComputat  ionOt  Demon 
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Appendix  C 

Package  Router  Development 


One  of  the  largest  and  most  interesting  GIST  specifications  to  date  is  that  of  a  mechanical 
package  router.  The  English  description  of  the  router  is  found  in  section  3.1 ,  and  the  formal 
Gist  specification  in  appendix  A.  Here  we  present  an  annotated  history  of  the  Glitter 
development53.  In  this  appendix  we  look  at  only  the  goals  posted  and  methods  selected; 
appendix  B  presents  the  goal/subgoal  structure,  appendix  D  the  selection  process. 


Structure  and  Notation: 

□  Development  steps.  We  will  present  the  development  as  an  alternating  series  of 
goals  and  methods  for  achieving  those  goals.  Goals  posted  by  the  user  will  be 
underlined  and  flagged  with  user,  all  other  goals  are  generated  as  a  byproduct  of 
problem  solving.  The  goal  syntax  has  been  sweetened  slightly  and  abbreviated 
from  the  actual  menu-driven  interaction  (see  section  2.3  3.2).  Noise  words  have 
been  added  for  readability.  Goals  which  are  trivially  satisfied  (i.e.,  hold  in  the 
posting  state)  will  generally  not  be  made  explicit. 

□  Program  snapshots.  Snapshots  of  the  program  development  state  will  be  given  to 
illustrate  the  effect  of  transformations  on  the  specification.  The  program  syntax  is 
described  in  chapter  3  and  appendix  A.  In  some  cases,  the  program  will  be 
annotated  with  k.s.  These  will  be  used  as  a  referencing  aid  from  within  the 
development. 

□  A  large  part  of  the  development  process  can  be  characterized  as  information- 
spreading.  Code  is  introduced  by  either  unfolding  or  maintaining  a  particular 
construct.  At  intervals  during  the  development  it  is  often  useful  to  regroup  by 
applying  simplification  transformations  which  attempt  to  both  get  rid  of 
unnecessary  buffer  code  and  use  the  local  context  to  optimize  spread  code. 
Simplification  is  not  carried  out  automatically,  but  must  be  explicitly  invoked 
through  the  Simplify  goal.  The  timing  of  the  simplification  or  clean-up  intervals  is 
left  to  the  user.  They  are  generally  chosen  after  major  surgery  has  been  done  to 
the  program.  For  readability,  we  have  taken  some  liberties  with  the  timing  and 


^Feather  and  London  have  developed  a  portion  of  the  package  router  by  hand  uaing  a  transformational  approach 
[London  a  Feather  82].  While  looking  at  only  a  portion  of  the  entire  development,  they  provided  a  large  number  of 
insights  into  the  overall  development  structure. 
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explicitness  of  simplification  steps:  we  use  them  more  frequently  than  is  typical 
and  generally  only  mention  that  simplification  has  taken  place,  leaving  the 
Simplify  goal  implicit.  Because  we  view  the  simplification  process  as  below  the 
planning  level,  we  believe  this  type  of  omission  will  make  the  development  easier 
to  follow. 

□  Trigger/response  assumption.  We  will  assume  that  the  response  of  a  demon  is 
executed  in  the  same  state  that  the  demon  was  triggered  in.  In  some  cases,  this 
puts  implicit  constraints  on  the  environment,  a.k.a.  gravity,  friction,  speed  of 
mechanical  sensors.  Normally  these  constraints  would  show  up  explicitly  as  a 
development  progressed;  we  forego  them  here  for  simplicity. 


A  development  digest:  For  presentation  purposes,  the  development  has  been  sectioned 
around  the  user's  high  level  development  goals.  Below  is  a  synopsis  of  each  section. 

1  .Remove  relation  PACKAGES_EVER_AT_SOURCE;  a  moderate  task.  No  need 
for  keeping  track  of  all  of  the  packages  that  enter  the  router,  just  the  last  one. 

2 . Remove  relation  PREVIOUS.PACKAGE;  a  moderate  task.  Removal  of 
"temporary  variable”. 

3.  Remove  relation  LAST.PACK  AGE;  an  easy  task.  The  only  information  that  need 
be  remembered  about  the  last  package  is  its  destination. 

4.  Map  constraint  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE;  a  difficult 
task.  Decide  switch  setting  strategy. 

5.  Map  relation  PACKAGES_DUE_AT_SWITCH;  a  difficult  task.  Find  way  to 
maintain  the  fundamental  data  structure  of  the  system. 

6.  Map  demons;  a  moderate  task.  Map  the  demonic  structure  into  triggerings  on 
observable  events. 
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C.l.  Remove  PACKAGES_EVER_AT_SOURCE 

The  package  router  specification  provides  for  keeping  the  sequence  of  fill  packages  that  ever 
enter  the  system  in  the  relation  PACKAGES_EVER_AT_SOURCE.  However,  the  only  use  the 
spec  makes  of  this  relation  (sequence)  is  to  access  the  las!  package  that  has  entered  the 
system;  keeping  the  entire  sequence  is  wasted  overhead.  The  development  will  start  with  the 
user  deciding  to  remove  the  unneeded  sequence  from  the  specification. 

Before  proceeding  with  the  development,  a  note  is  in  order.  The  process  of  removing 
PACKAGES_EVER_AT_SOURCE  was  the  portion  of  the  development  studied  in  detail  by 
Feather  and  London  [London  &  Feather  82].  A  number  of  the  steps  in  the  Feather  and 
London  (F&L)  development  have  a  Eureka  flavor:  without  an  overall  explicit  development 
plan,  they  appear  to  be  pulled  out  of  thin  air  to  allow  the  development  to  continue.  This  is  not 
a  criticism  of  the  F&L  development  in  particular.  In  fact,  it  was  a  rather  masterful  job.  Any 
development  which  captures  only  the  final  set  of  sequential  steps  that  went  into  the 
implementation  of  a  particular  spec  will  naturally  be  difficult  to  motivate.  Further,  a 
development  based  on  the  user  searching  through  a  catalog  of  transformations  for  a  "good" 
one  to  apply  generally  takes  the  flavor  of  opportunistic  search:  1)  try  applying  a 
transformation,  2)  if  it  produces  something  interesting,  continue  development  there,  else  3) 
goto  1.  Depending  on  the  complexity  of  the  spec  and  catalog  (expected  to  be  large  in  both 
cases),  this  is  not  a  good  model  of  development.  The  likelihood  of  missing  either  some 
important  step  or  the  right  order  of  step  application(found  to  be  a  crucial  constraint  in  a  Tl 
development)  is  great.  Planning  information  is  clearly  needed.  The  GLITTER  development 
provides  an  explicit  planning  structure  and  succeeds  in  rationalizing  most  of  the  steps;  ones 
remaining  unmotivated  (i.e.,  up  to  the  user)  are  discussed  as  to  their  resistance  to  future 
automation. 

Below  is  the  portion  of  the  spec  that  we  will  be  working  with  in  this  section: 
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demon  RELEASE.PACK AGEJNTO.NETWORK (package. new) 
trigger  package. new: located.at  ■  the  source 

re  am  nil 

bey  in 

if  ( the  package. previous  1 1 

package.previous  immediate! v  before  package. new 
►  j  Hi  PACK AGES_EVER_AT_SOURCE( * ) 

):  destination  *  package. new:  destination 
then  invoke  WAIT[]; 

update  : located_at  package. new  ig  (the  source ) : SOURCE.outlet 

fiM: 


relation  PACKAGES_EVER_AT_SOURCE(pacfcage_seq  |  seouence  of  package) 
definition  package jseq  * 

({ package  ||  (package  :LOCATED_AT  ■  Hn  source)  aaof  everbeforel 
ordered  temporally  by  start  (package: located. at  *  Un  source)); 


The  initial  goal  is  to  get  rid  of  the  sequence. 


STEP  1 .1  fuser):  Remove  PACK AGES.EVER  AT  SOURCE  from  spec 


|  Method  RemoveRelation 

Goal:  Remove  R  |  rotation  from  spec 
Action:  l)  fort'll  reference- local  1on(R,RR,  spec] 
do  Remove  RR  from  spec 
2)  Apply  WMOVE.UNWFINeNCeO.Pttl>TION(R) 

[You  can  remove  a  ralation  It  you  can  remove  all  ratarancat  to  It.] 
|  End  Method 


In  our  case,  there  is  only  one  reference  to  the  sequence:  the  one  ►1  found  in  the  derived 
object  package.previous. 

STEP  1 .2:  Remove  reference  ►1  to  PACKAGES_EVER_AT_SOURCE  from  spec 


The  entire  specification  or  root  of  the  parse  tree 
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|  Method  MegaMov# 

Goal:  Kamova  X |  ralation-ralaranca  from  spa e 
Filtar:  a)  componant-of[X ,  Yj 
Action:  1)  Itoiata  Y  In  DR  |  derived-relation 
2)  tJaintalnlncramantally  DR 

l Kamova  tha  ralation-ralaranca  X  by  moving  H  diractly  attar  tha  locations  It  is 
assigned] 

|  End  Method 


Note  that  the  component-of  relation  is  transitive.  Hence,  a  number  of  different  bindings  may 
occur  on  Y,  creating  a  separate  method  instantiation  for  each.  The  Y  we  have  chosen  is  the 
surrounding  derived-object.  We  could  have  also  chosen  the  more  immediate  context  of  the 
positional-retrieval.  In  this  case,  both  lead  to  the  same  basic  state. 

STEP  1.3  :  Isolate 

( the  package.previous  |  | 

package. previous  Immediately  before  package. new 
wrt  PACKAGES_EVER_AT_SOURCE( •  ) ) 


|  Method  FoldGenericIntoRelatlon  I 

Goal:  Isoiaia  X 
Action:  1}  Globalize  X 

2)  Apply  fouj.into.RELation(X) 

[Straightlorward  fold  into  derived-relation.] 

|  End  Method  I 


STEP  1.4:  Globalize 

( the  package.previous  \  \ 

package.previous  Immediate! v  before  package.new 
wrt  PACK AGES_EVER_AT_SOU RCE(  • ) ) 
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|  Method  Global ireDarlvadObJact  | 

Goal:  Globalize  00  j  derived-object 
Action:  l)  forall  raf*renca-locat1on[V,  S.  DO] 
tuchthat  V  *  locat-var-of]*,  DO] 
do  Try  Reformulate  V  at  global-expression 

[Try  changing  all  local  variable  r  ala  rone  as  to  global  ralarancas.] 

|  End  Method  | 

Note  the  use  of  the  Try  modifier  here:  each  Reformulate  goal  may  be  marked  as 
unrealizable  by  the  user. 

STEP  1.5:  Try  Reformulate  package.new  (in  derived-object  package. previous)  as 
global-expression 

|  Method  ReformLocal AsLatt  | 

Goal:  Reformulate  V|  variable  at  global-expression 
Filter-,  a)  pattern-match] 

dll.USR  (teq|umH££.  Si  type)  def;, 

R.  spec] 

b)  doma1n-typ#-of[type.  V] 

Action:  1)  Reformulate  V  as  lattfnameCU 

[il  you  can  fine  a  sequence  containing  the  same  type  of  objects  as  v  then  you 
may  be  able  to  change  V into  a  specific  reference  to  the  sequence.] 

|  End  Method  I 

This  method  looks  for  a  sequence  which  is  composed  of  the  same  type  of  objects  as  the 
variable  package.new ,  i.e.,  the  type  package. 

STEP  1.6:  Reformulate  package. new  as  lasMPACK  AGES«-EVEB*AT«-SOURCE(*)) 

At  this  point,  no  methods  succeed  in  achieving  the  goal.  The  user  has  two  options:  1)  since 
this  is  part  of  a  try-goal,  the  user  can  ignore  it  and  move  onto  the  fold  step,  or  2)  he  can 
manually  manipulate  the  program  to  achieve  the  goal.  If  the  latter  is  chosen,  which  it  is  in  this 
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case,  the  system  notes  the  problem  solving  context  for  future  (human)  analysis;  any  manual 
steps  taken  by  the  user  are  assumed  to  be  necessitated  by  some  missing  piece  of 
development  knowledge  in  the  system.  In  this  case,  it  is  lack  of  a  theorem  prover. 

STEP  1 .7  (user): 

Manual  manual-replace  {package. new,  lastf  PACK  AGES  EVER  AT  SOURCE(*)) 

This  is  the  first  operation  actually  carried  out  in  the  program  space;  in  the  base-line  Tl  system, 
this  would  be  the  first  arc  of  the  development  path  (see  the  F&L  development).  Without 
motivation,  i.e.,  the  six  subgoals  sitting  above  it,  it  appears  as  a  somewhat  lucky  or  Eureka 
step:  fortuitously  replace  an  expression  with  an  equivalent  value.  With  the  subgoal  hierarchy 
intact,  its  true  purpose  is  illuminated:  prepare  the  derived -object  for  isolation  (so  that  it  can  be 
maintained  so  that  the  reference  can  be  removed  ...).  Note  also  the  interaction  between  user 
and  system:  the  system  provides  the  focusing  and  motivation  while  the  user  is  responsible  for 
the  deep  reasoning  necessary  to  show  that  the  two  expressions  are  equivalent. 

After  replacing  the  local  with  a  global  expression,  we  have  the  following: 

(the  package. previous  \  \ 

package.previous  immediately  before  1ast(PACKAGES  EVER  AT  SOURCEC)) 
wrt  PACKAGES_EVER_AT_SOURCE(  * ) ) 

We  now  have  removed  all  reliance  on  local  variables  {package.previous  will  become  the 
necessary  *’ed  parameter).  If  any  did  remain,  the  same  two  options  of  ignoring  the 
globilization  goal  (allowing  them  to  become  parameters  in  the  newly  formed  derived  relation) 
or  finding  a  replacement  value  would  be  available. 

After  applying  the  relation  folding  transformation  foldjnto.relation  to  produce  a  new 
relation  PREVIOUS.PACKAGE55  ►1,  we  have  the  following 


When  the  system  needs  s  name  for  a  new  item,  it  asks  the  user  to  supply  it.  User  supplied  names  lead  to  much 
more  readable  programs.  With  a  sophisticated  name  generating  capability,  the  system  might  be  able  to  do  as  well. 
Currently  no  such  capability  exists. 
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demon  RELEA SE_P AC K A GE JNT O.NET  WOR  K  ( package. new ) 
trigger  package. new : located. AT  *  the  source 
response 
begin 

jf  PREV10US_PACKAGE(*) : destination  *  package. new : destination 
then  invoke  WAIT[]; 

update  :  located. at  al  package. new  la  l  the  source) : source.outlet 

sad: 


relation  PACKAGES_EVER_AT.SOURCE(pacAape_seg  |  sequence  of  package) 
definition  package jseq  * 

({ package  ||  (package :located_at  «  ihg.  source)  asof  everbeforel 
ordered  temporally  bv  start  (package : located. AT  «  the  source)); 


►j  relation  PREVIOUS_PACKAGE(pAev_pacfcape  |  package) 
definition  prev_package  * 

(A  package. previous  1 1 

package. previous  immediately  <  last f PACKAGES  EVER  AT  SOURCE(*)) 
►  ,  wrt  PACKAGES  EVER  AT  SOURCEf 


STEP  1 .8:  Maintainlncrementally  PREVIOUS.PACKAGE 


I 

Go  at:  Maintainlncrementally  DR  |  derived-relation 
Filter:  a)  -racurs1v»I0R] 

Action:  l)  Flatten  body-of(DR] 

2)  fora'll  r«feranca-locat1on[BR,  S,  DRJ 
do  forall  reforence-locattonJBR ,  L,  spec) 
do  bog  In 

Apply  WTBODUCE.M*INTEN*NCe_COOe(0R  L) 

Purity  L 
and 

P'0  maintain  a  derived  relation  DR.  find  everywhere  the  base  relations  of  DR 
are  changed  and  stick  code  in  to  maintain.  Make  sure  that  all  base  relations 
are  simple  before  maintenance  and  that  all  code  Is  pure  after.) 

|  End  Method  I 


|  Method  ScatterMalntonanceForOortvedRolatlon 


STEP  1.9;  Flatten  PREVIOUS.PACKAGE 
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Flattening  the  relation  body  is  a  simple  and  inelegant  way  of  insuring  that  all  relations  that 
PREVIOUS.PACKAGE  relies  on  are  found.  A  more  sophisticated  method  would  attempt  to 
analyze  the  relation  structure  to  determine  the  base  relation  set. 


|  Method  Flatten  | 

Goal:  Flatton  OR | derived- relation 
Action:  1)  fora'll 

reference- 1  ocat  Ion  [BR  |  dorivod-rolotion . S , DR] 
do  Map  BR 

(Map  all  derived  rotations  found  in  OR  into  simplo  o nos.) 

|  End  Method  I 


PACKAGES_EVER_AT_SOURCE  is  the  only  derived  relation  that  is  referenced  in  the 
PREVIOUS_PACK  AGES's  definition. 

STEP  1.10:  Map  derived-relation  PACK AGES_EVER_AT_SOURCE 

We  have  two  basic  choices  in  mapping  away  a  derived  relation:  unfold  it  everywhere  it  is  used 
(backward  inference);  maintain  its  value  at  places  where  its  base  information  changes 
(forward  inference).  We  have  chosen  the  latter. 


|  Method  MalntalnDerlvedRelatlon  f 

Goal:  Map  DR  |  dorivod-rolotion 
Action:  1)  Maintainlncromontally  DR 

(Ono  way  ol  mapping  a  dorivod  rotation  is  to  maintain  it  oxplicilly  ) 

|  End  Method  I 
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|  Method  IntroducaSeqMalntenanceDamon  | 

Goal:  Maintainlncramantally  DR|  derived-relation 
Filter:  a)  gist-type-of[paramater-of[DR]. 

sequence] 

Action-.  1)  Reformulate  body -of [DR] 

as  tempo rally-o rdered-aet  idiom56 
2]  Apply  INTRODUCE .8E0.MAMTENANCE.0EM0N( DR) 

[Ona  way  of  maintaining  a  derived  saguanca  Is  to  lirst  changa  the  dalinition 
into  a  temporal  order  -  UxllPIxlesol  averbatorai  ordered  temporally  fey  P(x» 

-  and  then  sat  up  a  demon  with  trigger  P(x)  to  add  elements.] 

|  end  Method  | 


The  relation  PACKAGES_EVER_AT_SOURCE  is  already  in  the  desired  form,  so  a  new 
C  ;inon  is  introduced,  NOTICE_NEW_PACKAGE_AT_SOURCE  >v  to  add  packages  to  the 
sequence  when  they  arrive  at  the  source: 


Pattsrns  can  be  predefined  and  named,  in  this  case.  <{x||P(x)  everbefore)  ordered  temporally  fey  start  P(x)). 
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demon  RELE A SE_P AC K A GE JNTO.NETWOR K ( package. new ) 
tripper  package. new : located_at  «  the  source 
response 
beoin 

if  PREVIOUS_PACKAGE(*):  destination  *  package. new :  destination 
then  invoke  WAIT[]: 

update  :located_at  gf  package. new  la  ( the  source) :  SOURCE.outlet 
&H4: 


relation  PACKAGES_EVER_AT_SOURCE(pacfcage_se<7  |  sequence  of  package); 

relation  PREVIOUS_PACKAGE(prev.pac/fage  |  package) 
definition  prevjtackage  • 

(A  package. previous  \  \ 

package. previous  immediate! v  before  1  astf PACKAGES  EVER.AT  SOURCE(*)) 
wrt  PACKAGES_EVER_AT_SOURCE(  • ) ) ; 

►  j  demon  NOTICE_NEW_PACKAGE_AT_SOURCE(pacfcage) 
triooer  package : located.at  *  the  source 
response 

►2  update  package  seq  la  PACKAGES_EVER  AT  SOURCE(S) 

‘  la  PACKAGESJEVER_AT_SOURCE( • )  co~ncat  <package> ; 


! 


Having  flattened  PREVIOUS.PACK AGE’s  body,  we  are  now  ready  to  maintain  it  by  finding 
all  the  places  its  base  information  (i.e.,  PACKAGES_EVER_AT_SOURCE)  changes.  There  is 
only  one  place  to  worry  about:  the  update  of  PACKAGES_EVER_AT_SOURCE  k2  in  the 
demon  NOTICE_NEW_PACKAGE_AT_SOURCE.  After  applying  the  maintenance 
transformation  introduce.maintenance.code,  the  program  is  as  follows: 


* 

4 


. 

I 

1 


H 


A  A  A' 
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demon  RELEASE_PACKAGE_INTO_NETWORK (package. new) 
tripper  package. new: located. at  *  the  source 
response 
beoin 

11  PREVIOUS_PACKAGE(*): destination  *  package. new : destination 
then  invoke  WAIT[]; 

update  :located_at  £l  package. new  ifi  ( the  source) :  SOURCE.OUTLET 

fiM: 


relation  PACKAGES_EVER_AT_SOURCE(package_seg  |  sequence  of  package); 

relation  PREVIOUS  PACKAGEforev  package  |  package); 

demon  NOTICE_NEW_PACKAGE_AT_SOURCE  (package) 
trigger  package: located.at  *  the  source 

rfi5JPfl5.fi 

atomic 

update  package _seq  In  PACKAGES_EVER_AT_SOURCE($) 

1S>  PACKAGES_EVER_AT_SOURCE  concat  <package> ; 
update  prev_package  in  PREVIOUS.PACKAGE(S) 
to  ( the  package. previous  |  | 

package. previous  immediately  before 

1  astf PACKAGES  EVER  AT  SOURCE(*)  concat  <package>) 
wrt  PACKAGES_EVER_AT_SOURCE( • )  concat  <package>) 

and  atomic 


Our  next  goal  is  the  purification  of  NOTICE_NEW_PACKAGE_AT_SOURCE:  if  that  demon  is 
not  within  our  portion  of  the  development  then  we  must  move  the  newly  introduced  code  out 
of  it  and  into  our  portion.  In  this  case,  we  have  defined  the  demon  as  part  of  our  portion  so  the 
goal  is  trivially  satisfied. 

We  have  now  achieved  our  goal  of  maintaining  the  derived  relation  PREVIOUS.PACKAGE. 
Further,  the  MegaMove  method  used  to  remove  the  sole  reference  to 
P A C K A GES_EVER_ AT_SO U RCE  has  completed.  However,  the  reference  has  not  been 
eliminated,  but  simply  moved.  As  described  in  chapter  5,  this  causes  the  remove  goal  from 
step  1.2  to  be  re-activated57.  The  system  automatically  keeps  track  of  the  movement  of  the 
reference  in  order  to  update  the  arguments  of  remove: 


57 


This  it  equivalent  to  a  recursive  potting  of  a  Remove  goal  at  the  last  action  of  MegaMove. 
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STEP  1.12:  Remove  reference  of  PACKAGES_EVER_AT_SOURCE  in 


from  spec 


(the  package. previous  1 1 

package. previous  immediately  before 

last(  PACKAGES  EVER_AT_SOURCE(*)  concat  <package>) 
wrt  PACKAGES_EVER_AT_SOURCE(* )  concat  <package>) 


Using  MegaMove  again  will  lose:  PREVIOUS.PACKAGE  (under  another  name)  will  simply  be 
re-introduced.  We  will  try  a  different  approach.  It  is  often  the  case  that  when  dealing  with  a 
sequence,  it  is  easier  to  manipulate  a  positional  retrieval  (e.g.,  first,  last,  Nth)  than  a  relative 
one  (e.g.,  (immediately)  before,  (immediately)  after).  The  method  we  will  employ  involves 
reformulating  the  relative  retrieval  into  a  positional  one  and  then  trying  MegaMove  on  that. 


|  Method  PosItlonalMegaMove  I 

Goal:  Remove  RR  |  relation- reference  from  spec 
Filter:  a)  RR  componant-of  Y 

Action:  1)  Reformulate  Y  as  PR  |  positional-retrieval 

2)  Isolate  PR  In  OR  |  derived-relation 

3)  Maintainlncremantally  DR 

[One  way  of  getting  rid  of  a  reference  to  a  sequence  is  to  reformulate  it  as  part 
of  a  positional  retrieval,  and  then  megamove  It  ] 

|  End  Method  I 


As  is  usual,  the  binding  we  choose  for  Y  is  important.  In  this  case  it  is  the  entire  derived 
object.  The  development  from  this  point  involves  several  low  level  reformulation  steps.  Note 
that  without  the  rich  teleology  provided  by  Glitter, these  steps  in  particular  and  low  level  steps 
in  general  are  hard  to  motivate  and  often  appear  fortuitous  in  a  base-line  development  (see  for 
instance  [London  &  Feather  82]). 

STEP  1.13:  Reformulate 

( the  package. previous  \  | 

package. previous  immediately  before 

/asf( PACKAGES  EVER_AT_SOURCE(*)  concat  <package>) 
wr t  PACKAGES_EVER_AT_SOURCE( • )  concat  <package>) 


as  positional-retrieval 
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t  Method  RaforMulatoDorlvadObjsct  | 

Goa/:  Rato rmulate  DO | derived-object  at  P 
Action'.  1)  Reformulate  body-of(DO] 

a*  local -var-ofl*.  DO]»P 
2)  Apply  UNFOkO.OCMVED.OaJCCT(DO) 

i  <xU  *  •  P)  ■»  p; 

|  End  Method  | 


P  is  bound  to  the  abstract  type  positional- retrieval.  Our  new  goal  is  to  reformulate  the  body 
of  the  derived  object  into  a  equivalence  relation  involving  the  free  variable  package.previous 
and  a  (any)  positional-retrieval. 


STEP  1.14  :  Reformulate 

package.previous  immediately  before 

iast( PACKAGES  EVER. AT  SOURCES)  concat  <package>) 
Ed  PACK  AGES_EVER.AT_SOURCE( • )  concat  <package>) 

as  package.previous* positional-retrieval 


|  Method  RaformulatoRolatlvaRatrlsvalAsLast  | 

Goal:  Reformulate  RS  |  relative-aequence-retrieval 

as  *x|o6yecr«^jULI(Soq|SEOucNCE)” 

Action:  1)  Reformulate  RS  as 

'X  lemiUlilJt  baron  y  an  (Seq  concat  z)’ 

2)  Equivalence  y  and  z 

3)  Apply  CMANOC.TO.Rrm€vw..or.LAST(RS) 

fa  Immediately  before  v  wrt  (Sag  concat  v)  •  x  « Iasi  (Sea)) 

|  End  Method  I 


Note  that  the  above  method's  trigger  will  match  positional-retrieval,  the  more  general  goal 
pattern,  with  lastfSeol.  the  more  specific  pattern  required  by  the  method.  Naturally,  there  will 
be  a  competing  method  to  the  above  that  attempts  to  reformulate  to  fiial(Seq). 


The  reformulation  goal  is  trivially  satisfied:  the  program  matches  in  the  current  state. 
However,  we  must  equivalence  y  and  z. 


|  Method  Anchor2 


Goal:  Equivalence  X  and  Y 
Action:  1)  Mo rmulata  X  as  Y 

[Try  changing  tha  first  construct  into  something  that  matches  the  second.] 
|  End  Method 
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l the  package.previous  1 1 

package. previous  •  last  (PACKAGES  EVER  AT  SOURCEQ) 

After  applying  transformation  unfold.derived.object  we  have: 

update  prev_package  in  PREVIOUS  PACKAGE(S) 

Ifi  last(  PACKAGES  EVER  AT  SOURCEf*)) 

The  reformulation  necessary  in  this  portion  of  the  development  is  caused  by  the  fussiness  of 
the  development  methods  we  employ.  All  of  the  above  reformulation  could  be  eliminated  if  we 
wished  to  include  a  method  which  looks  specifically  for  the  following  case: 

(x  ||  x  immediately  before  1  as t f s  concat  z) 

Mil  (s  concat  z)). 

Such  a  method  could  directly  reformulate  the  derived  object.  Of  course,  we  would  need  an 
infinite  number  of  such  methods  to  cover  all  of  the  possible  cases. 

We  are  now  ready  to  isolate  the  retrieval  of  PACKAGES_EVER_AT_SOURCE. 

STEP  1.17  I  Isolate  !asl(PACK AGES_EVER_AT_SOURCE(*)) 


|  Method  FoldGanaricIntoRelatlon  | 

Goa/:  /so/a/e  X 
Action:  l)  G/oOa/fte  X 

2)  Apply  POLO  JNTO_XELA  TON  (  X  ) 

(Straightforward  told  Into  darlvad-ralation.] 

|  End  Method  | 


There  are  no  local  variables  in  the  action  to  be  isolated,  hence  the  Globalize  goal  is  trivially 
satisfied.  Application  of  foldjnto.relation  results  in  the  introduction  of  a  new  derived 


relation  >2: 
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V, 


V. 


3 


■ 

A 


a 


demon  RELEASE_PACKAGE_INTO_NETWORK  (pacfcage.new) 
trigger  package. new : located.at  «  the  source 
response 
begin 

it  PREVIOUS_PACKAGE(*): DESTINATION  *  package. new : destination 
then  invoke  WAIT[]; 

update  :located_at  ni  package.new  in  ( the  source ) :  source.outlet 
flM: 

relation  PACKAGES_EVER_AT_SOURCE(pac*age_seo  |  sequence  of  package); 

relation  PREVIOUS  PACKAGEforev  package  |  package); 

demon  NOTICE_NEW_P AC K AGE.AT.SOU RCE ( package ) 
trigoer  package : located.at  ■  JfcM  source 
response 

atmic 

►  j  update  package jseq  in  PACKAGES_EVER_AT_SOURCE($) 

to  PACKAGES_EVER_AT„SOURCE  concat  <package>; 
update  prev_package  in  PREVIOUS  PACKAGE(S) 
in  LAST_PACKAGE(*) 
end  atomic: 

►2  relation  LA ST_P A C K AGE ( last_package  |  package) 

definition  last_package  -  lfl£i{  PACKAGES_EVER_AT_SOURCE) ; 


STEP  1.18:  Mainlainlncrementally  LAST.P  ACK  AGE 

We  will  use  the  same  method  here  to  maintain  LAST_PACKAGE  that  we  used  earlier  to 
maintain  PREVIOUS.PACKAGE: 


7. 
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t  Method  ScattarMalntenancaForDerlvadRelatlon  | 

Goal:  Maintetnlncrementally  DR  |  derived- relet  ion 
Action :  1)  Flatten  body-of[OR] 

2)  forall  refarance*tocat1on{BR.  S,  DR] 
do  forall  rafar#nca-locat1on[BR,  L,  spec) 
do  begin 

Apply  MTOOOueE.MANTENANCE.COOC(DR  L) 

Purify  L 
and 

/To  maintain  a  derived  relation  DP.  tlnd  everywhere  the  base  relatione  of  DP 
are  changed  and  stick  code  In  to  maintain.  Make  sure  that  all  base  relations 
are  simple  before  maintenance  and  that  all  code  Is  pure  after.] 

|  End  Method  I 


The  Flatten  goal  is  trivially  satisfied.  After  application  of  the  introduce.maintenance.CODE 
transformation  at  the  sole  place  where  PACKAGES_EVER_AT_SOURCE  is  changed  we 
have  the  following  state: 
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daman  RELE a SE_P AC  K  AGE JNTO_NETWO R K ( package. new ) 
trigger  package. new :  located.at  ■  the  source 
response 
begin 

it  PREVIOUS_PACKAGE(*):  destination  #  package. new: destination 
then  invoke  WAIT[]; 

update  :  located, at  at  package. new  ia  ( the  source) : SOURCE.OUTLET 

and: 

relation  PACKAGES_EVER_AT_SOURCE(paekage_seq  |  sequence  al  package); 

relation  PREVIOUS_PACKAGE(prev_package  |  package); 

demon  NOTICE.NE  W.P  A  C K AGE. AT.SOU RCE ( package ) 
trigger  package : located.at  ■  the  source 
response 
atomic 

update  package  seq  in  PACKAGES.EVER_AT_SOURCE($) 
la  PACKAGES.EVER.AT.SOURCE  concat  <package> ; 
update  prev _package  in  PREVIOUS.PACKAGE(S) 
la  LAST.PACK AGE( • ) ; 

►  ,  update  lastjjackage  in  LAST.PACKAGE(S) 

in  lastr  PACKAGES  EVER  AT  SOURCEf)  concat  <package> ) 
and  atomic; 

relation  LAST  PACKAGEf/asf  package  |  package); 


The  MegaMove  method  has  completed  and  we  still  have  not  gotten  rid  of  the  reference  of 
PACKAGES.EVER.AT.SOURCE.  However,  we  are  fairly  close  now.  The  Remove  goal  is 
re-activated: 


STEP  1 .1 9;  Remove  reference  of  PACKAGES.EVER.AT.SOURCE  in  ►1  from  spec 


Our  previous  strategy  has  been  to  isolate/maintain  (a.k.a.  MegaMove)  references  of  the 
sequence.  At  this  point,  we  have  enough  information  to  try  a  new  tact:  replace  the  sequence 
reference  by  an  actual  object. 
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|  Method  RemovaByObjaetlzIngContext  | 

Goa/:  flamov*  RR  |  re/el/on- reference  from  spoe 
Filter :  a)  component*of[RR,  Yj 
Action:  1)  Reformulate  Y  at  object 

10 no  way  ot  getting  rid  ot  a  rotation  raforonco  which  it  embedded  In  context  Y 
it  to  rotormulato  Y  as  an  explicit  obioct.] 

|  End  Method  | 


Here  we  bind  Y  to  the  most  immediate  context  of  the  reference,  the  positional  retrieval  last. 
STEP  1.20:  Reformulate 

1  ast/ PACKAGES  EVER  AT  SOURCEfl  concat  <package>) 
as  object 

Using  the  same  method  as  in  step  1.15,  ReformulateAsObject,  we  get  the  following: 
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demon  RELEA SE_PACKAGEJNTO_NETWOR  K  ( package. new ) 
tripper  pac/cage.new:COCATED_AT  ■  the  source 

faepin 

it  PREVIOUS_PACKAGE(»):  DESTINATION  *  package-new : DESTINATION 

then  jnygi&e  wait[]; 

update  :LOCATED_AT  gf.  package.new  in  ( the  source ) :  SOURCE.OUTurr 

and; 


*  a 


relation  PACKAGES_EVER_AT_SOURCE(pac/cage_seq  |  sequence  at  package): 

relation  PREVIOUS  PACKAGEforev  package  |  package); 

demon  NOTI CE_NE W.P A C K AGE. AT.SOU RCE ( package ) 
trigger  package : located. at  *  Un  source 
response 
atomic 

►  .  update  package jseq  jn.  PACKAGES_EVER_AT_SOURCE($) 

to  PACKAGES_EVER_AT_SOURCE  concat  <package>; 
update  prev_package  in.  PREVii0US_PACKAGE(S) 

la  last.packagec): 
update  last package  in  LAST.PACKAGE($) 
to  package 

fiM  Aiaoila: 

relation  LAST  PACKAGEf/as?  package  |  package); 


Note  that  this  last  step  is  traditionally  viewed  as  simplification  steps  which  are  automatically 
applied  whenever  possible,  e.g.,  lastfS  concat  X)  =*  X  (see  [Standish  et  al  76),  [Rutter  77)). 
These  type  of  steps  have  the  weakest  connection  to  the  rest  of  the  development.  They  appear 
to  be  independent  and  opportunistic.  Here,  we  strongly  tie  in  the  "simplification"  as  a 
necessary  step  in  the  higher  level  goal  of  removing  the  need  for  the  sequence 
PACKAGES_EVER_AT_SOURCE. 


1 


a 


We  have  one  remaining  reference  to  PACKAGES_EVER_AT_SOURCE  >2  that  we  must 
remove; 


STEP  1.21:  Remove 

update  package_seq  In  PACKAGES_EVER_AT_SOURCE(S) 
in  PACKAGES_EVER_AT_SOURCE  concat  <package> 

from  spec 


»> 
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daman  RELEASE.PACKAGEJNTO.NETWORK ( package. new ) 
trigger  package. new : located_at  ■  the  source 

L&szs.nis. 

begin 

11  PREVIOUS_PACKAGE(*):  DESTINATION  *  package. new : DESTINATION 
then  invoke  WAIT[]; 

update  :LOCATED_AT  &£.  package. new  Ifi  ( the  source)  :SOURCE_OUTLET 
AM; 


►  :  relation  PREVIOUS  PACKAGEforevoackaoe  |  package): 

►2  demon  NOTICE_NEW_P ACK AGE_AT_SOU RCE ( package ) 
trigger  package : located.at  «  the  source 
response 
atomic 

update  prev _package  in  PREVIOUS  PACKAGE(S) 

Ifi  LAST_PACKAGE(*) ; 
update  last _package  in  LAST.PACKAGE(S) 
to  package 
end  atomic : 

►3  relation  LAST_PACKAGE (last_package  |  package); 


This  completes  the  removal  of  the  PACKAGES_EVER_AT_SOURCE  relation.  However,  a 
new  demon  >2  and  two  new  relations  ►1,k3  have  been  introduced  as  side-effects  of  the 
removal  process.  The  next  two  sections  deal  with  further  developing  and  optimizing  these 
components. 
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£ 


C.2.  Remove  PREVIOUS.PACKAGE 


The  next  portion  of  the  development  involves  noticing  that  PREVIOUS_PACKAGE  is  acting 
as  a  temporary  variable  for  LAST.PACK  AGE. 


demon  NOTICE.NE W_P AC K AGE_AT_SOU RCE (package ) 
trigger  package : L0Cated_at  «  the  source 

rflspftnaa 

atomic 

►,  update  prevjjackage  ia  PREVIOUS.PACKAGE(S) 

Ifl  LAST_PACKAGE(*) ; 

►2  update  last jaackage  in  LAST.PACKAGE(S) 

to  package 
end  atomic: 

demon  RELE A SE_P AC K AGE _INT 0_NETW 0 R K ( package. new ) 
trigger  package. new: located.at  «  the  source 
response 

begin 

►3  11  PREVIOUS_PACKAGE(  •) : DESTINATION  *  package. new :  destination 

15  then  invoke  WAIT[]; 

update  :located_at  gf  package.new  ifi  ( the  source) :  source_outlet 
end : 

relation  PREVIOUS_PACKAGE(prev_pac*age  |  package); 
relation  LAST_PACKAGE(/asLpac*age  |  package); 


The  general  pattern,  if  we  wanted  to  do  this  noticing  automatically  is 

X  <-  Y; 

Y  <-  c; 

E | expression  using  X 


This  matches  the  following  code,  where  X  is  bound  to  PREVIOUS«-PACKAGE,  Y  bound  to 
LAST«-PACKAGE  and  E  to  the  conditional  wait  ►g. 


M 


•'  :\u  %V 
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atomic 

►  .  update  prev _package  in  PREVIOUS.PACKAGE(S) 

Ifl  LAST.PACK  AGE(  • ) ; 

►2  update  lastjjackage  in  LAST_PACKAGE($) 

to  package.new 
find  atomic: 

►  if  PREVIOUS_PACKAGE(*):  destination  *  package.new:  destination 

then  invoke  WAIT[]; 


We  can  generally  get  rid  of  the  need  for  X  (PREVIOUS_PACKAGE)  by  computing 
consecutively  the  assignment  of  X  with  its  use  (the  conditional  wait  t3)  and  replacing  X  with  Y 
(LAST.PACKAGE). 


STEP  2.1  fuser):  Remove  PREVIOUS.PACKAGE 


|  Method  RemoveRelatlon  I 

Goal:  Remove  R | relation  from  spec 
Action:  1)  fortll  reference-! ocat1on[R ,RR . spec] 
do  Remove  RR  from  spec 

2)  Apply  WM0Vt_UNREFERENC£D_R£l*T10N(  R  ) 

[ You  can  remove  a  relation  It  you  can  remove  all  references  to  It.] 

|  End  Method  I 


STEP  2.2:  Remove  reference  of  PREVIOUS.PACKAGE  in  from  spec 


|  Method  ReplaceRefWIthValue  I 

Goal:  Remove  R  |  simple-reletion-reference 
Action:  1)  Show  vaiuejwown ( R .  V) 

2)  Apply  bepi>CE.REF_withvalue(  R  V) 

(One  way  of  getting  rid  of  a  relation  reference  Is  to  replace  It  with  Its  value.) 

|  End  Method  I 


Note  that  another  competing  method  here  is  MegaMove.  That  is,  we  could  isolate  the 
reference  PREVIOUS_PACKAGE(*):destination  into  a  new  derived-relation  and  then 
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maintain  it.  However,  this  has  the  negative  effect  of  introducing  still  another  temporary 
variable  (relation).  While  we  can  get  rid  of  this  too  eventually,  the  process  will  be  messier.  In 
general,  a  method  which  removes  a  reference  by  replacing  it  with  a  value  is  preferred  over  a 
method  which  replaces  it  (or  its  surroundings)  with  another  reference. 

STEP  2.3:  Show  value_known(PREVIOUS_PACKAGEC),  V) 


|  Method  ShoeUpdat-eGiveaValue 

Goal:  Show  vALue,KNOWN(R|re/at/on-r*ference,  V) 

Filter:  a)  pattern-match[wpdefe,  u.  epee] 

b)  name-of[R]  ■  update-relatton-of[P .  U] 

Action:  1)  Show  UPOATE_VALUE.MOLDS( U .  R) 

2)  Assert  value.known(R,  new-value-ofl* .  U] ) 

[Find  the  last  update  of  A  and  show  that  the  new  value  is  still  valid.] 

|  End  Method 


There  is  only  one  update  of  PREVIOUS.PACKAGE  in  the  spec,  the  one  found  in 
NOTICE  <-NEW«-PACKAGE«-AT*-SOURCE.  We  now  must  show  that  the  value  the  relation 
was  set  to  is  still  around. 

STEP  2.4  :  Show 

LAST_PACK AGE( • )  (in 
still  holds  at 

►,  H  PREVIOUS_PACKAGE(*): destination  *  package. new: destination 
then  WAIT[] ; 


C.2  Remove  PREVIOUS.PACKAGE 
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|  Method  ShowNewValueStillVal  id  | 

Goal:  Show  upoate.v«.ue.molds(U| update , 

R  |  rotation  reference) 

Filter:  a)  name-of[fi]  «  updata-ralat lon-of [• ,  U) 

Action :  1 )  Show 

UNCHANQED.BETWEEN.LOCATlONS(nee-wa1ue-Of[»,  U),  U,  R) 

3)  Assart  u*>oate.value.molos(U.  R) 

[T o  show  that  the  now  update  value  is  still  around  at  R,  show  that  the  update 
value  has  not  been  changed  before  A.J 

|  End  Method  | 


STEP  2.5:  Show  LAST_PACKAGE  doesn’t  change  between  ►1  and  ►g. 


|  Method  MovelntervenlngUpdate 


I 


Goal :  Show  uncmanoeo.BETWEEn.locatons(  V  |  relation  reference . 

U  |  update. 

R  |  relation  reference) 

Filter:  a)  pattern-match[i/pcfare,  L,  spec] 
b)  update-re1at1on-of[V,  L) 

Action  ■.  l)  Show  computation Au.v»arrwEEN[L ,  u,  R] 

2)  ComputoSequontially  R  before  L 


1 11  an  Intervening  update  of  V  exists,  move  It  after  R.J 
|  End  Method 


In  this  case,  there  does  exist  an  intervening  update  >2  to  V  (LAST.P  ACK  AGE),  and  hence  we 
will  try  to  move  it  after 


STEP  2.6:  ComputeSequentially 

K  it  PREVIOUS_PACKAGE(*): DESTINATION  neo  package. new : destination 
lUlft  Invokt  WAIT[] ; 
before 

►2  update  last_package  la  LAST_PACKAGE(S) 

to  package.naw 
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|  Method  MovaOutOf Atomic  I 

Goo/:  ComputeSeQuentlally  B | action  before  A | action 
Fitter:  a)  co«ponant-of[A,  C | atom/e] 

Action  :  1)  Untold  C 

[H  you  art  trying  to  move  A  attar  B  and  A  la  In  an  atomic,  untold  tha  atomic 
batora  attampting  to  continua  l 

|  End  Method  I 

STEP  2.7:  Unfold 

atomic 

update  prev_package  ift  PREVIOUS_PACKAGE(S) 

1ft  LAST_PACKAGE(*) ; 
update  lastjjackage  in  LAST_PACKAGE(S) 
to  package 
Mg  atomic: 


|  Method  UnfoldAtonlc  I 

Goal:  Untold  A| atomic 

Action:  1)  Snow  8EOucNTi*i.oeoeaiNO(0| ordering.  A) 

2)  Show  supeafiuous_ato»*C(A) 

3)  Apply  untoi.D-atomic(A,  0) 

[You  can  untold  an  atomic  It  you  can  ahow  that  thara  exists  aoma  valid 
sequential  ordering  of  tha  atatamanta  and  that  no  damonic  or  intarancing 
procaasas  will  be  effected.] 

|  End  Method  I 

Currently  the  user  is  required  to  show  both  of  the  properties.  In  the  particular  case  at  hand,  it 
would  not  be  difficult  to  define  a  method  for  ordering  the  statements  using  a  data-dependency 
graph,  something  Glitter  presently  does  not  have.  Showing  that  the  atomic  is  actually 
superfluous  will  probably  remain  the  user's  responsibility  for  some  time  to  come. 

After  unfolding,  the  program  is  as  follows: 
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demon  NOTICE_NEW_PACKAGE_AT_SOURCE(package) 
trigger  package : located.at  ■  idfi  source 
response 

begin 

►  .  update  prevj>ackage  in  PREVIOUS  PACK AGE(S) 

Ifi  LAST_PACKAGE(*) ; 

►2  update  lasl_package  in  LAST.PACKAGE(S) 
to  package 

find; 

demon  RELEASE_PACKAGE_INTO_NETWORK(package.neM’) 
trigger  package./iew:  located.at  «  the  source 
response 

begin 

►3  11  PREVIOUS.PACKAGE(') : DESTINATION  *  package. new: destination 

then  invoke  WAIT[]; 

update  :  located.at  flf  package. new  ifi  (lh£  source) :  SOURCE.OUTLET 

find: 

relation  PREVIOUS  PACKAGEforev  package  |  package); 

relation  LAST  PACKAGEf/asf  package  |  package); 


STEP  2.8 (reposted):  ComputeSequentially 

►3  il  PREVIOUS.PACK AGE(  • ) :  destination  nfifi  package. new :  destination 
then  invoke  wait[]; 

before 

►2  update  last_package  jn  LAST_PACKAGE(S) 

to  package.new 


|  Method  Consol IdateToMakeSequentlal  | 

Goal:  ComputeSequtntltliy  Al|  action  before  A2 lection 
Filter:  a)  camponant-of [A1 .  D1  (demon] 

Action:  1)  Consolidate  D1  and  D2 

[It  It  easier  to  move  ectlons  eround  If  they  ere  In  the  same  context.] 

|  End  Method  | 


STEP  2.9:  Consolidate 
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NOTICE_NEW_PACKAGE_AT_SOURCE 

and 

RELEASE  J>ACKAGE_INTO_NETWORK 


|  Method  MergeDamons  | 

Goal:  Consolidat a  D1  (demon  and  D2| demon 
Action:  l)  Equivalence  trlgger-offDl]  and 

tr1gger-of[D2] 

2)  Equivalence  var-declaraflon-of[01]  and 

var>dedaratton-of[D2] 

3)  Show  mcroeable.demons( D1 .  02,  I  (ordering) 

4)  Apply  DeMONMCftOE(01,  02,  I) 

[ You  can  conaoliOata  two  demons  It  you  can  chow  that  thay  have  tha  tama 
local  variables.  tha  aama  trig  paring  pattarn  and  that  thay  maat  c attain 
marging  conditions.] 

|  End  Method  | 


STEP  2.10:  Equivalence  {package.new)  and  (package) 


|  Method  EqulvalancaCompoundStri>ctures2  I 

Goal:  Equivalence  S 1 1  compound-structura  and 
S2 1  compound-structure 

Fitter:  a)  gl*t-typt-of[,)  SI]  •  glat-type-ofl*.  S2] 

b)  -f  1xed*»tructurelSl] 

c)  component-correspongence[Sl.  S2.  C  |  correspondence] 

Action-.  1)  fortH  corra*pond#nce-pa1r*[C.  Cl.  C2] 

St£  Equivalence  Cl  and  C2 

fO/v/da-and-conquar:  make  tha  components  of  two  non-f/xad  structures 
equivalent.) 

|  End  Method  I 

EquivalenceCompoundStructures2  will  compute  a  correspondence  between  the  variables  in 
the  list  (in  this  case  only  one  exists)  and  post  an  equivalence  goal  pair. 


STEP  2.11:  Equivalence  package  and  package.new 


C.2  Remove  PREVIOUS.PACKAGE 
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We  can  use  the  brother  of  method  Anchor2  (see  step  1.15)  to  achieve  the  Equivalence  goal 
here. 


|  Method  Anchorl  | 

Goal-.  Egulvalanc a  X  and  Y 
Action:  1)  Reformulate  Y  as  X 

[Try  changing  tha  aacond  construct  into  aomathing  that  matchas  tha  first.] 

|  End  Method  | 


STEP  2.1 2  :  Reformulate  package  as  package.new 

The  achievement  of  this  goal  rests  on  the  renaming  of  package  to  package.new  within 
NOTICE*-NEW<-PACKAGE«AT*-SOURCE. 


|  Method  RenameVar  | 

Goal:  Raformulata  VI  j  variable-declaration  as 

V2 1  variable-declaration 

Filter:  a)  scoped-  1n(Vl  S] 

Action:  1)  Show  mt*oouc£abie-vab-name(V2  .  S) 

2)  Apply  rename_var  ( VI ,  V2 ,  S) 

[Raplaca  all  occurrancas  of  VI  with  V2  In  S  altar  showing  that  V3  does  not 
conflict  with  scopad  variables  already  defined  within  S.] 

|  End  Method  | 


We  assume  that  the  user  verifies  that  the  introduction  of  package.new  does  not  conflict  with 
any  existing  variables  within  NOTICEa-NEWa-PACKAGEa-ATa-SOURCE.  After  the 
renaming,  the  equivalence  goal  on  the  triggers  is  trivially  satisfied.  The  application  of 
DEMON  MERGE  gives  US 
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dAmon  RELEASE_PACKAGE_INTO_NETWORK (package. new) 
triopar  package. new : located.at  ■  the  source 

cuftfln m 

ban  in 

P.  uodata  prevjtackage  in  PREVIOUS.PACKAGE(S) 

ifi  LAST_PACKAGE( • ) ; 

►  2  uodata  last_package  in  LAST_PACKAGE(S) 

to  package,  new 

P,  it  PREVIOUS_PACKAGE(*) : destination  *  package. new : destination 
”  than  invoke  WAITH; 

update  :located_at  at  package. new  in  ( the  source) :  SOURCE.outlet 
CM; 


relation  PREVIOUS_PACKAGE(prev_package  |  package); 
relation  LAST_PACKAGE (lasi_package  |  package); 


The  ComputeSequeniiaily  goal  from  2.8  is  still  not  satisfied  and  hence,  is  reposted. 


STE  P  2 . 1 3  (reposted):  ComputeSequentially 

P,  it  PREVIOUS_PACKAGE(*  ) ;  destination  nag  package. new : destination 

innn  .in Yoke  wait[]; 

before 

Pj  update  last_package  in  LAST.PACKAGE(S) 

to  package.new 


|  Method  SwapUp  I 

Goal:  ComputeSequentially  Y  before  X 
Filter:  a)  brother-of JX,  Y] 

Action :  1)  Swap  Y  with  predecessor  of  V 

(It  you  are  trying  to  compute  X  alter  Y  then  move  Y  up.) 

|  End  Method  | 


C.2  Remove  PREVIOUS.PACKAGE 
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STEP  2.1 4:  Swap 

►  ,  il  PREVIOUS_PACKAGE(*):  destination  *  package. new : destination 
then  Invoke  WAIT[]; 

with 

►2  update  lasl_package  1q  LAST_PACKAGE($) 
to  package. new ; 


|  Method  SwapStatements  | 

Goal:  Swap  A  with  B 

Action :  1)  Show  swappable  (A  B) 

2)  Apply  swap.$tatements(A  B) 

(A;B  «•  B;A  under  certain  conditions.) 

|  End  Method  j 


Again,  with  a  data-dependency  graph,  the  swappable  property  might  automatically  be 
verified.  Currently,  we  rely  on  the  user  to  verify  it.  After  applying  the  swap  transformation,  we 
have: 

beain 

►  ,  update  prevjjackage  iD.  PREVlOUS_PACKAGE(S) 

1  ifi  LAST.PACKAGEC); 

►  ,  If  PREVIOUS.PACK  AGE(  • ) : DESTINATION  *  package. new : destination 

then  invoke  wait[]; 

►2  update  lasij>ackage  in  LAST.PACKAGE(S) 

to  package. new 

update  :LOCATED_AT  package. new  in  ( the  source ) : SOURCE.OUTLET 

fiM: 


t 

i 


The  ComputeSequentially  goal  has  now  been  satisfied.  After  the  application  of  the  value 
replacement  transformation  replace.ref.with.value  and  the  removal  of  the  maintenance 
and  definition  (see  steps  1.20  and  1.21)  of  PREVIOUS.PACKAGE,  we  have: 
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demon  RELE A  SE_P A  C  K  A  GE_INTO_NET W  0  R  K  ( package,  new ) 
triooar  package. new: located. at  ■  the  source 

rfi  5P0nS.fi 

begin 

11  LAST_PACKAGE(*): destination  *  package. new : destination 
then  invoke  WAIT[]: 
update  lasijjackage  in  LAST.PACKAGE(S) 
to  pack  age.  new 

update  :located_at  fif  package.new  Ifl  ( the  source ) :  source.outlet 
£01; 


relation  LAST_PACKAGE(/asf_pacfcape  |  package); 


C.2  Remove  PREVIOUS.PACKAGE 
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C.3.  Remove  LAST.PACKAGE 


The  next  portion  of  the  development  involves  noticing  that  we  don't  need  to  remember  the  last 
package,  but  only  its  :DESTination  ►  .  We  might  expect  an  automatic  usage  analysis  to  point 
out  such  features  of  the  program.  Such  an  analysis  is  certainly  state-of-the-art  and  should  be 
one  of  the  more  immediate  enhancements  to  the  Tl  system. 


demon  RELEASE_PACKAGE_INTO_NETWORK (package. new) 
trigger  package. new: located.at  «  the  source 
response 
begin 

►  j  it  LAST_PACKAGE(*): DESTINATION  *  package. new: destination 
then  invoke  WAIT[]; 
update  last_package  in  LAST.PACKAGE(S) 
to  package. new 

update  :LOCATED_AT  fif  package. new  ig  ( the  source ) :  SOURCE_OUTLET 
Md; 

relation  LAST  PACKAGEf/asf  package  |  package): 


Note  that  remembering  all  of  an  objects  attributes  instead  of  the  object  itself  may  not  payoff  in 
cases  where  a  large  number  of  the  object's  attributes  are  needed:  we  may  simply  be  replacing 
a  central  "record"  structure  (an  object  and  its  attributes)  with  individual  variables  (the 
isolated  relations).  In  our  case,  only  one  field  is  ever  needed,  and  hence  we  can  perceive  an 
efficiency  gain. 

STEP  3.1  fuser):  Remove  LAST.PACKAGE 


We  will  employ  the  same  general  "MegaMove"  strategy  as  used  in  removing  the 
PACKAGES  EVER  ATSOURCE  in  section  C.1 . 
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|  Method  RomoveRelatton  | 

Goal:  Remove  R  |  relation  from  apme 
Action :  1)  forall  roference-locat1on[R,RR,spec] 
do  Remove  RR  from  spec 
2)  Apply  mmove.unreferenceo.klatkm(  R ) 

[ You  can  remove  a  rotation  It  you  can  remove  all  ralarancas  to  It.] 

|  End  Method  I 


STEP  3.2:  Remove  reference  of  LAST.PACKAGE  in 


|  Method  MegaMove 


I 


Goal:  Ramova  X | rotation- rataranca  from  spec 
Filter:  a)  componant-of[X ,  Y} 

Action :  l)  Isolate  Y  in  DR  |  derived- re/etion 
2)  Ualntainlncramantally  OR 

/Remove  the  rolation-rotoronco  X  by  moving  It  directly  altar  the  locations  It  is 
assigned.] 

|  End  Method  | 


We  choose  the  binding  of  Y  as  LAST.PACK  AGE(*):oestination. 
STEP  3.3:  Isolate  LAST_PACKAGE(*):destination 


I  Method  Fol46ener1clntoRe1at1on  | 

Goal:  Isolate  X 
Action.  1)  Globalise  X 

2)  Apply  foldjnto.hclatiOn(  X  } 

I Straightforward  told  into  derived-relation.] 

|  End  Method  | 


After  applying  fold. into. relation,  we  have: 
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demon  RELE A SE_P A C K AGE _l NTO.NET WO R K ( package. new ) 
tripper  pac/cage.new:LOCATED_AT  »  the  source 
response 
beg  i  n 

■if  LAST.PACK AGE.DESTIN ATION  ( • )  *  package. new :  DESTINATION 
1M!1  invoke  WAIT[]; 
update  last_package  la  LAST.PACKAGE(S) 
to  package.new 

update  :located_at  al  package.new  la  ( the  source) : source.outlet 
end ; 

relation  LAST  PACKAGE(/asf  package  |  package); 

relation  LAST_PACKAGE_DESTINATION(/asf_desf/naf/on  |  bin) 

definition  la$t_destination  *  LAST_PACKAGE(  • ) :  destination  ; 


STEP  3.4:  Maintainlncrementally  LAST.PACK  AGE.DESTIN  ATION 


|  Method  ScatterMalntenancaForDaMvedRelatlon  | 

Goal :  Maintainlncramentally  DR  |  derived- relation 
Action  :  1)  Flatten  body  of  [DR] 

2)  fora'll  ref«rence*locat1on[BR,  $.  DR] 
do  forall  rtfarenca-locatlon[BR ,  L,  spec) 
do  bag  In 

Apply  INTeOOUCC.MANTCNANCE.COOE(DR  l) 

Purity  l 
end 

f  To  maintain  a  derived  relation  DP,  find  everywhere  the  base  relations  ot  DP 
are  changed  and  stick  code  In  to  maintain.  Make  sure  that  all  base  relations 
are  simple  before  maintenance  and  that  all  code  Is  pure  after.] 

|  End  Method  I 


e  .e 
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demon  RELEASE.PACKAGEJNTO.NETWORK  (packege.new) 
trigger  package. new : located_at  »  the  source 

r.ft5,BM5.& 

begin 

It  LAST.P  ACK  AGE  DESTIN  ATiON  { • )  *■'  package. new :  DESTINATION 
iten  invoke  WAIT[]; 
atomic 

►  j  update  last_package  in  LAST_PACKAGE($) 

Ifi  package. new, 

►2  update  lasijdestination  in  LAST_PACKAGE_DESTIN ATION  ( S ) 

to  package. new: destination 
£Q4  atomic 

update  :located_at  nl  package. new  in  (the  source) :  SOURCE.OUTLET 

ind; 

relation  LAST.P  ACK  AGE  ( Iasi  jtackage  |  package); 
relation  LAST.P  ACK  AGE.DESTIN  ATION  (/asf_desf/naf/on  |  bin); 


We  have  now  achieved  our  goal  of  removing  one  of  the  references  to  LAST.PACK  AGE.  The 
next  reference  is  part  of  the  maintenance/update  of  LAST.PACK  AGE. 

STEP  3.5:  Remove  reference  to  LAST.PACKAGE  from  ►1 

We  will  omit  the  steps  here  of  removing  this  reference  and  the  relation  definition.  They  are 
completely  analogous  to  the  steps  found  at  step  1 .20-1 ,21 .  Our  new  state  is 


££&  ‘./.A,*  cVl  '<M1 


$ 
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demon  RELE A SE_P AC K A GE_INTO_.NET WO R K ( package. new ) 
trigger  package. new :located_at  «  the  source 
response 
beoin 

11  LAST_P ACK  AGE.DESTINATION  ( *  )  *  package. new :  DESTINATION 
then  invoke  WAIT[]; 

►,  atomic 

update  lastjdestination  in.  LAST_PACKAGE_DESTiNATfON(S) 
to  package. new :  destination 
end  atomic 

update  : located. at  £l  package. new  ifl.  ( the  source) : SOURCE.outlet 

find; 


k  m 


relation  LAST  PACKAGE  DESTINATION ( last  destination  |  bin); 
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STEP  4.2  :  Show 

3  package, switch  |  | 

►.  (package: located. at  ■  switch 
and 

►  S  WITCH_SET.WRONG.FO  R_P  A  C  K  A  GE  ( switch,  package ) 

and 

►3  (( package  -  firsts  PACKAGES  DUE  AT  SWITCH ( * . switch ) ) 

and 

SWITCH_IS_EMPTY(sw/fch))  Alfil  everbefore^t 
implies  Q 


|  Method  Conjunetlmpt  IssConjunctArm  | 

Goal:  Show  X | conjunction  Implies  Y 
Finer:  a)  unbound! Y] 

b)  conjuct-srm[A  |  logical-expression ,  X] 

Action:  1)  Assert  X  Impiias  A 

l(P1  ana  P2  and  ...Pn)  implies  Pf 

|  End  Method  | 


There  are  three  possible  choices  for  A  corresponding  to  the  three  conjunct  arms: 

1.  ►1  Trigger  when  a  package  becomes  located  at  a  switch;  guarantee  that  either 
the  switch  is  set  right  or  that  there  never  was  a  chance  to  set  it  right56. 

2.  *2  Trigger  when  the  switch  is  set  wrong;  guarantee  that  the  package  is  not  at  the 
switch  or  that  there  never  was  a  chance  to  set  the  switch  right. 

3.  >3  Trigger  when  there  is  a  chance  to  set  the  switch  right;  guarantee  that  the 
package  is  not  at  the  switch  or  that  the  switch  is  set  right. 

We  will  choose  the  third: 

(( package  »  fi  rstf  PACKAGES  DUE  AT  SWITCH  (•.switch)) 
and 

SWITCH JS.EMPTY ( switch ) )  asof  everbefore) 

The  effect  of  peformulate.constraint.as.demon  can  be  characterized  as  follows: 


66  Actually,  you  only  hava  to  make  this  guarantee  as  long  as  the  triggering  predicate  holds.  This  Is  true  tor  the 
other  two  cases  as  well. 
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always  prohibit  P 

demon 
trigger  Q 

response  reouire  (~P  f ram  ThisEvent  unti/1  -0) 
where  P  implies  Q 

Define  a  demon  who  triggers  on  O  and  posts  a  requirement  that  P  not  be  true  between  the 
time  the  demon  triggers  (Q  becomes  true)  and  Q  becomes  false. 


After  application  of  this  transformation  (and  a  straightforward  removal  of  the  historical 
reference  from  the  trigger  and  simplification  of  the  requirement  conjunction),  we  have  the 
following: 


demon  SET.S W ITCH_ WHEN.H A VE_CH A N CE ( switch ,  package ) 

trigger  ( package  «  f  i  rstf  PACKAGES  DUE  AT  SWITCHf  *  .switch)) 
and 

SWITCH JS.EMPTY  ( switch ) ) 

response 

require  ( - ( package : locateo.at  ■  switch 
and 

SWITCH_SET_WRONG_FOR_PACKAGE(sw/fch.pacAape) ) 
from  ThisEvent 68 

►.  until  -(( package  « 

f  irstf  PACK  AGES_DUE_AT_SWITCH  ( • ,  switch ) ) 
and 

SWITCH_IS_EMPTY [switch))  asof  everbeforel) 


The  response  of  the  new  demon  should  be  read  as  "require  that  the  package  not  be  located 
at  the  switch  when  the  switch  is  set  wrong .  Make  sure  that  this  is  true  from  the  time  the  demon 
triggers  until  the  switch  is  not  ready  to  be  set,  »  asof  everbefore  «".  The  until  clause  is 
clearly  false  since  the  trigger  implies  that  the  switch  has  been  ready  to  be  set  in  the  past.  A 
simple  transformation  of  the  until  clause  k2, 

. . .  until  false  until  evermore 

allows  us  to  simplify  (SET.SWITCH  is  included  for  context): 


se 


i.e..  the  triggering  of  this  demon. 
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►  .  demon  SET.S WITCH (sw/feh) 
trinoer  RANDOM( ) 
response 
bJ.fl.jn. 

require  SWITCH  _IS_EMPTY  ( switch  )  ; 

update  :  SWITCH.SETTING  fit  switch  £fi  switch :  SWITCH_OUTLET 
finfi; 


demon  SET_SWITCH_WHEN_HAVE_CHANCE(sw/fch .  package) 

trigger  ( package  *  f i rstf  PACKAGES  DUE  AT  SWITCH (m. switch)) 
and 

SWITCH  _IS_EMPTY  ( switch  )  ) 

response 

reaui  re  (-(package :  LOCATED.AT  *  switch 
and 

SWITCH_SET_WRONG_FOR_PACK  AGE(sw//e/7,pac*ape  ) ) 
f  rom  ThisEvent 

►,  until  evflnnpre 


STEP  4.3*.  Map  SET  SWITCH  WHEN  HAVE.CHANCE 


|  Method  MapByConso 1 ldatlon 
Goa/.-  Map  D | demon 

Fitter-,  a)  pattern-match[demon,  02.  spec] 
b)  D  *  02 

Action-.  1}  Consolidate  D  and  02 

[To  map  D.  find  soma  other  demon  D2  and  consolidate.] 
I  End  Method 


»*i*i*i  iSn 
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|  Method  MtrgaDtmons  j 

Go*/:  Consolidate  Dl| demon  end  02 1 demon 
Action:  l)  Equivalence  trlgger-of [Dl]  tnd 

tr1gg#r-of|D2] 

2)  Equivalence  v*r-d*cl*r*t1on-of[Dl]  end 

w«r-d#c1«r*tion-of[D2) 

3)  Show  mcroeable.demons(01.  02,  I|o rdering) 

4)  Apply  DCMON.MEnOE(01.  02.  1) 

l You  can  consolidate  two  demons  If  you  can  show  that  they  have  the  same 
local  variables,  the  same  triggering  pattern  and  that  they  meet  certain 
merging  conditions .] 

|  End  Method  | 


STEP  4.5:  Equivalence 

triooer  RANDOM( ) 
and 

trigger  package  «  first!  PACKAGES  DUE  AT  SWITCH ( » . switch ) ) 
and 

SWITCH  JS.EMPTY  (switch ) 


|  Method  Anchor2 

Goal  :  Equivalence  X  and  Y 
Action  :  1)  Reformulate  X  as  Y 

t  Try  changing  the  first  construct  into  something  that  matches  the  second  ] 
|  End  Method 


STEP  4.6:  Reformulate  RANDOMO  as 

package  «  f  i  rstf  PACKAGES  DUE  AT  S  WITCH  (•.switch)) 
and 

SWITCH  JS_EMPTY  ( switch ) 
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|  Method  Special IzoRandoffl 

Goal:  Reformulate  X| RANDOM  as  Y | expression 
Action:  1)  Show  non.empty.specialization( Y) 

2)  Apply 

REPLAC£.RANOOM_WrrH_8PEClAUZATION(X  Y) 

[You  can  always  raplace  RANDOM  with  a  more  specialized  event  It  you  can 
show  tha  naw  avant  doas  not  ramova  all  choicas.J 

I  End  Method 


We  rely  on  the  user  to  show  that  a  non-empty  subset  of  triggerings  remain  for  SET_S WITCH. 


After  the  application  of  replace_random_with_speciau2ation,  we  have 


demon  SET_S WITCH  ( switch ,  package ) 

triooer  package  ■  f irstf  PACKAGES.DUE.AT.SWITCH  ( •  .switch ) ) 
and 

SWITCH  JS.EMPTY  (switch) 

response 


update  :  SWITCH.SETTING  ill  switch  ifl  switch :  switch_outlet 
where  SWITCH  JS.EMPTY  (switch) 

find; 


demon  SET_SWITCH_WHEN_HAVE_CHANCE(  switch,  package) 

triooer  ( package  «  IjjjK  PACKAGES.DUE.AT.SWITCH  (•  ,switch) ) 
and 

SWITCH  JS.EMPTY  (switch ) ) 

response 

require  (-(package: located. at  »  switch 
and 

S  WITCH.SET.WRONG.FO  R_PACKAGE(  switch,  package ) ) 
from  ThisEvent 


Our  Equivalence  goal  has  been  achieved  and  we  can  consolidate  the  two  demons. 


>vli' 
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demon  SET_S  WITCH  (sw/fc  ft ,  package) 

trigger  package  •  first* PACKAGES  DUE  AT  SWITCH**  .switch )) 
and 

SWITCH  JS_EMPTY  ( switch ) 

response 

begin 

update  :  switch  setting  fil  switch  Jtfi  switch : SWITCH.OUTLET 
where  SWITCH _IS_EMPTY ( switch ) ; 

►j  reguire  ( ~  ( package :  located.at  ■  switch 

and 

S  WITCH_SET_WRONG_FO  R.P  A  C  K  AGE  ( switch, package ) ) 
f  rom  This  Event 
Mill  evermore 

AM; 


We  have  removed  the  global  constraint  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
from  the  program,  but  are  left  with  a  residual  iocal  constraint  ►1  within  SET_S WITCH. 

STEP  4.7 (user):  Map 

►j  reouire  ( - ( package :  located.at  «  switch 

and 

SWITCH_SET_WRONG_FOR_PACKAGE(sw/fch,pacfcage) ) 
from  ThisEvent 
until  evermort 


|  Method  CasIfyPoaConstralnt  I 

Goa/:  Map  C  |  +  constraint 
Action  :  1}  Cosily  C 

2)  forall  casa-of(X,  C)  do  Map  X 

[Try  mapping  by  cate  analysis  ] 

|  End  Method  I 


The  remainder  of  the  development  in  this  section  will  be  based  on  a  number  of  different  case 
analysis  strategies  for  removing  the  requirements  in  the  SET.SWITCH  demon.  The 
interaction  between  the  user  and  system  during  this  time  points  out  the  fundamental  role  of 
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each:  the  system  suggests  rather  broad  strategies  with  keystone  pieces  left  unbound;  the  user 
selects  among  the  strategies  based  on  his  ability  to  fill  in  the  missing  pieces.  The  latter  activity 
requires  what  we  might  call  the  insightful  or  intelligent  component  of  reasoning;  we  suspect 
that  such  activity  will  resist  automation  for  some  time  to  come. 

STEP  4.8:  Casify 

►  j  require  (-(package : LOCATED.AT  »  switch 
and 

SWITCH_SET_WRONG_FO  R_PACKAGE($w/'tch, package ) ) 
f  rom  ThisEvent 
until  evermore 


|  Method  CasIfyFromUntllEverConstralnt 

Goal  :  Casify  C|  *  constraint 
Action:  1)  Reformulate  C  as 

P  from  E  until  evermore 
2)  Apply  CAStrv.AS.NOW.AND.ATTEn  ( C ) 

[ You  can  show  that  C  holds  from  £  until  avarattar  If  you  can  show  It  holds  at  E 
and  altar  £./ 

|  End  Method 


This  method  makes  the  following  transformation 

+  constraint  P  from  E  until  evermore 

+  constraint  P  at  E: 

*  constraint  P  after  E; 

In  our  case,  this  means  showing  that  either  the  package  is  not  located  at  the  switch  or  that  the 
switch  is  set  right  at  the  time  the  demon  triggered  ►1  and  for  all  time  after  k2.  After  application 
of  CASIFY_AS_NOW_AND_AFTER,  W6  have80 


60 

Note  that  the  reformulation  goal  is  trivially  satisfied.  This  is  because  earlier  we  carried  out  the  reformulation  for 
clarity.  Normally  this  would  be  carried  out  here  where  it  is  well  motivated. 
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STEP  4.10:  Map 

►.  require  ( - ( package : located, at  ■  switch 

and 

S  WITCH_SET_WRONG_FOR_P  ACK  AGE  ( switch, package ) ) 
after  ThisEvent 


|  Method  CasIfyPosConstralnt  | 

Goa/:  Map  C|  *  constraint 
Action :  1)  Caslfy  C 

2)  forall  cats*of[X,  C]  do  Map  X 

f  Try  mapping  p y  caaa  analysis.] 

|  End  Method  | 


STEP  4.11:  easily 

►  ,  require  ( - ( package : LOCATED. at  «  switch 

and 

SWITCH_SET_WRONG_FORJ>ACKAGE(sw/fc/7.pac/cape)) 
after  ThisEvent 


|  Method  CasIfyAroundEvant  | 

Goal:  Caslly  C  |  constraint 

Action:  1)  Ralormulata  C  as  constraint  P  after  E 

2)  Show  run«E.EvEMT(  F ,  E) 

3)  Apply  C  *srv. ABOUND. E  vent  ( C ,  F) 

/Choose  soma  avant  F  In  tha  tutura  and  show  that  C  holds  balora,  during  and 
attar  F.J 

|  End  Method  | 


This  method  splits  a  constraint  into  three  cases:  1)  before  some  future  event  F,  2)  during  F 
and  3)  after  F.  in  this  case,  the  difficult  task  is  picking  the  right  future  event  F.  We  rely  on  the 
user  to  make  this  choice: 

bind  F  to  package : located_at  >  switch 

After  application  of  Casipv.apound.event,  we  have  our  before  Pv  during  ►.  and  after  ►, 


3 
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demon  SET.S WITCH  (switch ,  package)  ■ 

trigger  package  «  ii£ii( PACK  AGES_DUE_AT_SWITCH ( • , switch ) ) 
and 

SWITCH  JS.EMPTY  (switch ) 

response 

begin 

►0  update  :  switch.SETTING  fil  switch  switch :  Switch.outlet 

where  SWITCH_IS_EMPTY(sw/fc/t) ; 

►.  require  ( - ( package : located.at  ■  switch 

and 

SWITCH_SET_WRONG_FOR_PACKAGE(sw/fch,pac/cape)) 
after  ThisEvent  until  package : located.at  «  switch; 
►2  reoui  re  (-(package :  LOCATED.AT  ■  switch 

and 

S  WITCH_SET_W  R  ONG_FOR_P A  C  K  A  GE  ( switch, package ) ) 
during  package : located.at  ■  switch; 

►  ,  reoui  re  (-(package:  located.at  ■  switch 

and 

S  WITCH_SET_WRONG>FOR.P  AC  K  AGE  ( switch. package ) ) 
after  package : LOCATED.AT  «  switch; 


Again,  we  must  map  each  of  the  new  cases. 


STEP  4.1 2:  Map 


require  (-(package .-located.at  *  switch 
^nd 

SWITCH_SET_WRONG_FOR>ACKAGE(sw/tch,pac*ape)) 
after  ThisEvent  until  package : located.at  «  switch; 


|  Method  NotXUntllX 

Goa/:  Map  P  |  +  constraint 

Action:  1)  Ratormulata  R  as  *  constraint  P  until  E 

2)  Show  w«.*o.bv(P^  -E) 

3)  Apply  MMOVE.VACUOU8.CONSTBAIMT(  R  ) 

l P  until  £  m  trua  whan  -£  impllaa  P] 

|  End  Method 


\  WrJrJrTi r*V 
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We  rely  on  the  user  to  show  that  the  negation  of  the  until  clause  ••  the  package  is  not  located 
at  the  switch  implies  the  predicate.  We  can  thus  remove  the  first  requirement  By  (the 
user)  showing  that  the  package  will  never  again  return  to  the  switch  after  it  leaves  it,  we  can 
similarly  remove  the  third  requirement  ►g.  This  leaves  us  with  the  second  requirement  k2. 

STEP  4.1 3:  Map 

>2  require  (-(package: located.at  ■  switch 

and 

SWITCH_SET_WRONG_FOR_PACKAGE(sw/fch,package) ) 
during  package : located. at  «  switch ; 


We  can  simplify  this  to 

require  -SWITCH.SET_WRONG.FO R.P  ACK  AGE ( switch, package ) 
during  package .-located.at  ■  switch: 

We  will  again  use  case  analysis  to  simplify  the  problem. 


|  Method  CasIfyPosConstralni  | 

Goal  :  Map  C  |  *  constraint 
Action :  l)  Gasify  C 

2)  forall  case-of[X,  C)  do  Map  X 

[ Try  mapping  by  case  analysis.] 

|  End  Method  | 


STEP  4.1 4:  Casify 


require  -SWITCH  _SET.WRONG_FOR.PACK A GE ( switch, package ) 
during  package: located.at  «  switch ; 
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|  Method  Past  Induct  Ion  | 

Goal:  easily  C  |  *  constraint 

Action  :  1)  Reformulate  C  as  *  constraint  P  during  E 

2)  Show  EVEWT_BEfOfl£.EVENT{B,  E) 

3)  Apply  PASTJWUCTlON_CASIFY(C,  B) 

[Use  induction  from  soma  past  state.] 

|  End  Mothod  | 


This  method  makes  the  following  transformation: 

*  constraint  P  during  E 

*  constraint  P  4i  B  1 1  B  before  E 

*  constraint  -( start  $1  -P)  between  B,  after  E 

To  paraphrase,  there  exists  some  state  B  before  E  where  P  holds  and  P  does  not  change 
between  B  and  E.  The  choice  of  B  is  naturally  critical  and  is  left  to  the  user: 

bind  B  to  last  update  g±  switch :SWItch_setting  in  SET.SWITCH  (►„) 
After  application  of  past_induction_ca$ify,  we  have 


demon  SET_SWITCH (switch,  package) 

trigger  package  •  firstf  PACKAGES  DUE  AT  SWITCH  f  *  .switch) ) 
and 

SWITCH  JS.EMPTY  ( switch ) 

response 

begin 

►0  update  :  switch_setting  g±  switch  switch :  switch.outlet 

where  SWITCH  \SJEMPTY  (switch) ; 
require  ~S  WITCH_SET_WRONG_FORJ>ACK  AGE  (switch,  package) 
tt  last  update  of  switch : switch_setting ; 

>2  require 

~( start  Ql  ~S  WITCH_SET_WRONG_FOR_PACKAGE(sw/fcb, package ) ) 
between  last  update  gi  switch : switch.setting , 

package :  located.at  ■  switch 

a&ii 
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STEP  4.15:  Map 

►  ,  require  -SWITCH.SET.WRONG.FOR.PACKAGEfsw/fcb.pacAage) 
At  last  update  of  switch : switch.setting ; 


|  Method  MovaConstralntToAction  | 

Goal :  Map  C  |  faquir  a 
Action :  1)  Reformulate  C  at 

require  P  H  last  E  |  Action-event 

2)  Show  last_action( A | action,  E) 

3)  Apply  move.constbaint.to.action(C,  A) 

Ilf  a  constraint  C  is  on  soma  action  event  E  at  A,  attach  the  constraint  to  A.] 

|  End  Method  | 


We  rely  on  the  user  to  show  that  the  update  of  the  switch  setting  ►1  in  SET_SWITCH  is  the 
only  update  of  a  switch  setting  and  hence,  it  must  have  been  the  last.  After  application  of 
MOVE_CONSTRAINT_TO_ACTION,  We  have 


demon  SET_SWITCH(sw/fc/7 ,  package) 

trigger  package  ■  JjxSJU  PACKAGES_DUE_AT_SWITCH(»  .switch) ) 
and 

SWITCH  JS.EM  PTY  ( switch ) 

man  se 

begin 

►0  update  : switch  setting  flf  switch  switch: switch  outlet 

where  S WITCH JS.EM PTY ( switch) 
and 

~SWITCH_SET_WRONG_FOR_PACKAGE(sw/fch,pac/cage) ; 

>2  require 

-(start  fil  ~S  WITCH_SET_WRONG_FOR_PACK  AGE  (sw/fch, package ) ) 
between  last  update  gf  switch : switch_setting , 

package :  located. at  •  switch 

fiJld: 


STEP  4.1 6:  Map 
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-(start  -SWITCH_SET_WRONG_FOR_PACKAGE(sw/(ch,package)) 
between  last  update  of  switch : switch.setting , 

package :  located. at  «  switch 


|  Method  ShowNoChange 

Goal:  Map  C  |  *  constraint  -/start  of  P) 
between  E1.E2 

Action :  1)  Show  uwCHwtoeo.BeTWEEN.6VEWTS( P .  El.  E2) 
2)  Apply  REMOVE.UNCMANOEO.CONSre*MT(C) 

[ The  direct  approach.] 

|  End  Method 


STEP  4.1 7  :  Show 

-(start  gf  ~SWITCH_SET_WRONG_FOR_PACKAGE(stv/(c/7,pac*age)) 
between  last  update  of  switch :  switch.setting ,  package: located_at  «  switch 

Showing  that  the  switch  is  never  set  wrong  (relative  to  a  particular  package)  once  it  is  set  right 
lies  beyond  the  capabilities  of  the  system.  We  rely  on  tne  user  to  assert  the  necessary 
property. 

After  application  of  remove.unchanged.constraint,  we  have 


demon  SET_SWITCH( switch,  package ) 

trigger  package  «  f  i  rst(  PACKAGES  DUE  AT  SWITCH  (•.switch)) 
and 

SWITCH  JS.EMPTY  ( switch ) 

EtiMit 

►0  update  : switch.setting  gf  switch  l &  switch : switch_outlet 
where  SWITCH_IS_EMPTY (switch) 
and 

~SWITCH_SET_WRONG_FOR_PACKAGE(  sw/fcb, package ) ; 


Our  last  task  will  be  to  map  the  non-deterministic  choice  of  switch  settings  ►<,  using  the 
attached  constraints  as  a  guide. 
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STEP  4. 1 8 (user):  Map 

►0  update  :SWITCH_SETT»NG  a£  Switch  switch : SWITCH  OUTLET 
where  SWITCH _l  S.EMPTY  (switch) 
and 

~SWITCH_SET_WRONG_FOR_PACKAGE(  switch, package) ; 


|  Method  ComputeNewVtlue  | 

Goal:  Map  U I  update  t  jf  V  i  where  P 
Action:  1)  Apply 

C0MPLrrE.DeRiVED.oejecT.rnoM.coNsnuiNT{  U ) 

, Reformulate  Z  as  darivad  obfact  using  P.J 

|  End  Method  | 


The  application  of  compute_oerived_object_from_constraint  gives  us 


demon  SET_SWITCH {switch ,  package ) 

trigger  package  ■  first  (PACKAGES  DUE  AT  SWITCH  ( * .  switch )  ^ 
and 

SWITCH_IS_EMPTY  {switch) 

response 

update  : switch_setting  switch  1SL 

( pipe  ||  pipe  •  switch :  SWiTCH_0UTLET 
and 

SWITCH  JS.EMPTY  ( switch ) 
and 

►  j  ~SWITCH_SET_WRONG_FOR_PACK  AGE  (switch, package) ; 
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|  Method  ScaUerComputatlonOfDarlvtdRalatlon  | 

Goal-.  Untold  OR  | derived- relation  at  L 
Fitter :  a)  rafartnca-locat1on[DR,  L,  S] 

Action  1)  Apply  UNTOU)_COMPUTATION_COOe(DR  L) 

2)  Purity  L 

f To  untold  a  derived  relation  DP  at  a  reference  point,  stick  in  code  to  compute 
It  and  make  sure  L  Is  within  implementable  portion  ot  spec.} 

|  End  Method  I 


Unfolding  SWITCH_SET_WRONG_FOR_PACKAGE  ►1  and  simplifying  (see  example  A, 
section  E.14)  gives  us 


•  •  • 

demon  SET_S WITCH (sw/fc/) ,  package) 

trigger  package  «  f  i  rst(  PACKAGES  PUE  AT  SWITCH (*  .switch}) 
and 

SWITCH  JS.EMPTY  (switch ) 

response 

update  :  SWITCH_SETTING  fif  switch  ifi. 

( pipe  1 1  pipe  «  switch :  switch_OUTLET 
and 

►,  SWITCH_IS_EMPTY  {switch) 

and 

LOC  ATION_ON_RO  UTE_TO_BIN  ( pipe , 

package :  destination  ) ) ; 


Finally,  we  can  get  rid  of  the  empty  switch  constraint  >2  under  our  assumption  that  the 
response  of  a  demon  is  executed  in  the  same  state  as  it  was  triggered: 


C.4  Map  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
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demon  SET  SWITCH  {switch ,  package) 

triooer  package  -  fi  rstf  PACKAGES  DUE  AT  SWITCH ( • . switch ) ) 
and 

SWITCH  JS.EMPTY  ( switch ) 

response 

update  :  switch.setting  fli  switch  Ifl 

( pipe  ||  pipe  •  switch :  switch_OUTLET 
and 

LOCATION_ON_ROUTE_TO_BIN ( pipe , 

package :  destination  ) ) ; 
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C.5.  Map  PACKAGES_DUE_AT_SWITCH 

We  will  focus  our  attention  on  the  derived  relation  PACKAGES_DUE_AT_SWITCH: 


relation  PACKAGES_DUE_AT_SWITCH(packape$_due  |  sequence  of  package. 

switch) 


definition  packagesjdue  ■ 

{A  package  | | 

LOCATION_ON_ROUTE_TO_BIN(svv/fch  package : DESTINATION ) 
and 

-( (package : located.at  *  switch)  asof  everbeforel 
and 

-MISROUTED  (package ) 

}  ordered  temporally  by  start  (package: located.at  «  the  source)); 


Abstractly,  the  sequence  of  packages  is  defined  in  terms  of 


{S}  ordered  with  respect  Event 


A  package  is  in  the  set  of  packages  S  if  conjunctively 

□  LOCATION_ON_RO UTE_T 0_BI N (switc h ,  package: destination)  i.e.,  the  switch 
lies  on  route  to  the  package’s  destination. 

□  ~((pac/cage :located_at  *  switch)  asof  everbefore).  i.e.,  the  package  has  not 
already  reached  the  switch. 

□  ~MISROUTEO(pacfcage),  i.e.,  the  package  is  still  expected  to  show  up  at  some 
future  time  at  the  switch. 

STEP  5.1  fused:  Map  PACKAGES_DUE_AT_SWITCH 

As  in  previous  sections,  we  have  two  basic  strategic  choices:  compute  on  demand;  compute 
on  change.  We  will  choose  the  latter  here. 
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|  Method  MalntalnDerlvadRelatlon 

Goa/:  Map  DR  |  derived- relation 
Action:  1)  Maintalnlncrementally  DR 

/One  way  of  mapping  a  0 erived  rotation  is  to  maintain  It  explicitly.] 

I  End  Method 


STEP  5.2:  Maintalnlncrementally  PACKAGES_DUE_AT_SWITCH 


|  Method  SeatterMalntenanceForDerlvedRelatlon 

Goal:  Maintalnlncrementally  DR 

Filter:  a)  gif t-type-of[DR .  derived-relation] 

Action:  1)  Flatten  body-of[DR] 

2)  forall  reference-locat1on[BR.  S,  DR] 
do  forall  reference-1ocat1on[BR,  l,  epee) 
do  begin 

Apply  ermoouci.MAiNTENANCE.cooE(DR  L) 
Purity  l 


[To  maintain  a  derived  reletion  DP,  lind  everywhere  the  base  relations  ol  DR 
are  changed  and  stick  code  In  to  maintain.  Make  sura  that  all  base  relations 
are  simple  before  maintenance  and  that  all  code  is  pure  attar.] 

|  End  Method 


STEP  5.3:  Flatten  PACK AGES_DUE_AT_S WITCH 


Method  Flatten 

Goal:  Flatten  DR  | derived-relation 
Action:  1)  forall 

reference-1  ocat1on[BR  |  derived- relation,  S .  DR] 
do  Map  BR 

[Map  all  derived  relations  found  In  DR  into  simple  ones.] 
End  Method 
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Before  maintaining,  we  must  first  get  rid  of  any  nested  derived  relations.  There  are  currently 
two.  LOCATION_ON_ROUTE_TO.BIN  and  MISROUTED. 


STEP  5.4:  Map  LOCATJON_ON_ROUTE_TO.BIN 


relation  LOC ATION_ON_ROUTE_TO.BIN (LOCATION , BIN) 
definition 

case  LOCATION  qL 

BIN  «*»  LOCATION  «  BIN; 

PIPE 

LOCATION.ON.RO  UTE_T0.BIN  ( 

LOCATION:  connection_to_switch_or.bin , BIN) ; 

SWITCH 

^  LOCATlON_ON_ROUTE_TO_BIN(LOCA7/OW:Switch_outlet.B/N) ; 
SOURCE 

=*  L0CATI0N_0N_R0UTE_T0_BIN(L0CA7/0W:source_outlet,B/W) ; 
end  case : 


We  can  either  choose  to  compute  LOCATION«-ON«-ROUTE*-TO«-BIN  on  demand  (i.e., 
unfolding  it)  or  maintain  it  explicitly.  Since  the  relation  is  static,  maintenance  looks  most 
promising. 

|  Method  StortExplIcItly  | 

Goal:  Map  DR  |  derived-relation 
Filter :  a)  static(DR) 

Action  :  t)  Show  FINm.EXPLCATON(  DR ) 

2)  Apply  INrriAUEE.MEMO.RIlATION ( H ,  DR) 

3)  fort'll  locat1on-r#ftrtnct[DR.  L,  tptc] 

do  Apply  REPVACE-REF  wrTH  MEMO(  L  .  M) 

4}  Apply  remove.unrefer£nced_reiatk>n{DR) 

[You  can  explicitly  compute  a  static  derived  relation  given  a  finite  number  of 
resulting  db  insertions.] 

|  End  Method  | 


initialize.memo.relation  will  define  a  new  memo  relation  and  code  to  initialize  it. 
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relation  MEMO_LOCATION.BIN ( location ,  bin); 

demon  INITIALI2E_MEM0_L0CATI0N.BIN (  ) 
trigger:  ( start  initialization _st ate)*1 
response 

loop  L  I  LOCATION  jB[fi 

loop  8  I  BIN  II  LOCATION.ON  ROUTE  TO_BIN(L.  8) 
insert  MEMOJ.OCATION_BIN(L,  8) ; 


We  can  now  replace  references  to  LOCATION_ON_ROUTE_TO.BIN  with  corresponding 
references  to  MEMO_LOCATION.BIN  trivially  except  for  the  initialization  above.  Here,  we 
will  use  some  loop  transformations  to  get 


relation  MEMO_LOCATION_BIN(/ocaf/on,  bin); 

demon  INITIA  U2E_MEMO_LOCATION.BIN  (  ) 
trigger:  (start  initialization jstate) 

.rascQPsa 

begin 

loon  8  |  bin  Hfi  insert  MEMO_LOCATION_BIN(8, 8) ; 
loop  L  |  LOCATION  |  | 

MEMO_LOCATION_BIN(L ,  8)  aM 
L  *  L2:  CONNECTION  TO  SWITCH_OR_BIN 
insert  MEM0_L0CATI0N_BrN(l2,  8) ; 

end 


We  next  have  to  deal  with  the  derived -relation  MISROUTED. 


STEP  5.5:  Map  MISROUTED 


81 A  special  state  proceeding  the  start-up  of  a  system. 


\v 


1  V*  « 


-a.  it  ■v’  v-  O.  ^y^-.vW'V  jJ. 
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relation  MISROUTED( package) 
definition 

~MEM O.LOC ATI ON.BIN  (package :  located.at  ,  package :  destination  ) 
££ 

S  WITCH_SET_WRONG_FO  R_P  A  C  K  A  GE  ( package :  c  ( 1  ocated_at ) . 

package ) ; 


To  paraphrase,  a  package  is  misrouted  if  either  its  current  location  is  not  on  the  route  to  its 
destination  or  if  it  is  at  a  switch,  the  switch  is  set  wrong. 

In  the  case  of  this  derived  relation,  we  will  try  a  backward  inference  strategy  of  computing  the 
relation  on  demand. 


|  Method  UnfoldDerlvedRelatlon  | 

Goaf:  Map  OR  |  derived*  relation 

Action :  1)  forall  ref  trance- 1  ocation[DR ,  L.  spec] 
do  Unfold  DR  at  L 

/One  way  of  eliminating  a  derived  ralatlon  is  to  unfold  It  at  Its  reference 
points.) 

|  End  Method  | 


STEP  5.6;  Unfold  MISROUTED  at  PACKAGES_DUE_AT_SWITCH 


|  Method  ScatterComputatlonOfDertvedRelatlon  | 

Goaf:  Unfold  OR  | derived-relation  at  L 
After:  a)  reference-locat1on{DR.  L,  S] 

Action :  1)  Apply  UNf cxd.COMputaton.COOE  ( DR  L) 

2)  Purify  l 


(V 


& 


[To  untold  a  darivad  ralatlon  DP  at  a  reference  point,  stick  In  coda  to  compute 
It  and  make  sura  L  Is  within  impiementable  portion  of  spec.) 

|  End  Method  I 


a,:,  V, 


>s 


n 


A 

A 


a 

ME" 


ifajfv’ifcueJ'eJ 
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relation  PACKAGES_DUE_AT_SWITCH(packages_c/ue  |  sequence  of  package, 

switch) 


definition  packages jiue  « 

{A  package  1 1 

MEM O.LOC  ATION_BI N ( switch  package : destination) 
and 

~( (package :located_at  »  switch )  asof  everbefore) 
and 

~  ( -MEM  O.LOC  ATI  ON.BI  N  ( package :  LOCATED.  AT , 

package :  destination  ) 


SWITCH_SET_WRONG_FOR_PACKAGE(package :  LOCATED.AT , 

package ) ) 

}  ordered  temporally  bv  start  (package :  located,  at  *  the  source)); 


The  Flatten  method  has  completed,  but  a  new  derived-relation  has  been  introduced: 
SWITCH_SET_WRONG_FOR_PACKAGE,  i.e.,  the  Flatten  goal  has  not  been  achieved.  The 
goal  will  be  re-activated. 


STEP  5.7:  Flatten  PACK  AGES.DUE.AT_S  WITCH 


|  Method  Flatten  | 

Goal:  Flatten  DR  |  derived-relation 
Action:  1)  forall 

ref  e  rence- 1  oca  1 1on[BR  |  derived-relation ,  S .  OR] 
do  Map  BR 

/Map  all  derived  relations  found  In  PR  into  simple  ones  ] 

|  End  Method  I 


PACKAGES.DUE.AT.SWITCH  now  relies  upon  the  derived  relation 
SWITCH.SET.WRONG.FOR.PACKAGE  which  was  introduced  in  the  unfolding  of 
MISROUTED. 
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relation  SWITCH_SET_WRONG_FOR_PACKAGE(sw//c/J, package) 
definition 

MEMO_LOCATION.BIN  ( switch ,  package :  DESTINATION ) 
and 

-MEMO _LOC ATION.BIN  (switch :  SWITCH.SETTING ,  package :  DESTINATION ) 


To  paraphrase,  a  switch  is  set  wrong  for  a  package  if  the  switch  is  along  the  route  to  the 
package’s  destination  and  its  current  setting  is  not. 

STEP  5.8:  Map  SWITCH_SET.WRONG.FOR.PACK AGE 


ft 


ft 


|  Method  UnfoldDarlvedRelatlon  | 

Goa/:  Map  DR | derived-relation 

Action:  1)  forall  rafaranca-1ocat1on[DR.  L.  spec] 
do  Untold  OR  at  L 

[One  way  ot  eliminating  a  derived  relation  it  to  untold  It  ait  Its  reference 
points.] 

|  End  Method  I 


STEP  5.9:  Unfold 

PACKAGES.DUE.AT.SWITCH 


SWITCH.SET.WRONG.FOR.PACKAGE 


at 


Method  ScatterCofflputatlonOfDarlvedRe'litlon 


Goa/:  Untold  O*\derlvod~relation  at  L 
Filter :  a)  reference-1ocat1on[DR.  L.  $] 
Action :  1)  Apply  untold.COmp^  atoh.COM  ( DR  L) 
2)  Purity  L 


[ To  untold  a  derived  relation  DP  at  a  reference  point,  stick  In  code  to  compute 
It  and  make  sure  L  la  within  Implejnentable  portion  ot  spec.] 


|  End  Method 


Unfolding  SWITCH.SET.WRONG.FOR.PACKAGE  in  PACKAGES.DUE.AT.SWITCH  we 

have 


C.5  Map  PACKAGES_DUE_AT_SWITCH 
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relation  PACKAGES_DUE_AT_SWITCH(packages_due  |  sequence  of  package. 

switch ) 

definition  packagesjdue  * 

{t  package  1 1 

MEM 0_L0CATI0N.BIN { switch  package :  destination) 
and 

"((package: LOCATED. at  «  switch)  asof  everbeforel 
and 

►  j  -(-MEMO.LOC  ATION.BIN  (package :  LOCATED.  AT , 

package :  destination  ) 

££ 

3  switch.2  1 1 

(package :  located.at  *  switch.2 
and 

MEMO_LOCATION_BIN(sw/fc/).2 .  package : destination) 
and 

~MEMO_LOC  ATION.BIN  ( switch.2 :  SWITCH.SETTING . 

package :  destination  ) ) ) 

}  ordered  temporal  1  v  start  (package: located.at  «  iM  source))'. 


Distributing  the  negation  through  the  third  term  (►.,)  gives  us 


relation  PACKAGES_DUE_AT_SWITCH{pacfcapes_due  |  sequence  of  package. 

switch) 

def  in  it  ion  packagesjdue  « 

{i  package  | | 

MEMO_LOCATION.BIN (switch  package:  destination) 
and 

-((package: located.at  «  switch)  asof  everbeforel 
and 

►2  ( MEMO.LOC  ATION.BIN  ( package :  LOCATED.AT , 

package :  destination  ) 
and 

-3  switch.2  1 1 

(package :  located.at  «  switch.2 
and 

►,  MEMO_LOCATION_BIN(sw/fcb.2,  package :  destination ) 

And 

-MEMO.LOC  ATION.BIN  ( svitch.2 :  SWITCH.SETTING , 

package :  destination)  ) ) 

}  ordered  temporally  by.  start  (package: located.at  «  Un  source))'. 


Finally,  we  can  show  that  the  third  term  >2  implies  that  our  current  location  is  on  route  to  our 
destination  (Pg)  and  therefore  that  if  we  are  at  a  switch,  it  is  on  route  to  our  destination: 
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relation  PACKAGES_DUE_AT_SWITCH(pac*ages_due  |  sequence  of  package, 

switch ) 

definition  packages jiue  ■ 

{A  package  | | 

MEMO_LOCATION.BIN {switch  package : destination) 
and 

~{ (package : located_at  *  switch)  asof  everbefore) 
and 

( MEM 0_L0CATI0N.BIN  (package :  LOCATED.AT , 

package :  destination) 
and 

-3  switch.2  1 1 

(package :  located.at  *  switch.2 
and 

~MEMO_LOCATION.BIN  ( switch.2 :  SWITCH_SETTING , 

package :  destination)  ) ) 

}  ordered  temporal  1  v  bv  start  (package :  LOCATED.AT  «  the  source))-. 


We  have  now  flattened  the  body  of  PACKAGES_DUE_AT_SWITCH  and  are  ready  to  scatter 
the  maintenance  code.  The  locations  of  interest  are 

1.  where  pac  fcage  :destination  changes  ■  CREATE.PACKAGE 

2.  where  package:  location  changes,  i.e-,  negates  the  second  term 

CREATE.PACKAGE,  RELEASE_PACKAGE_INTO_NETWORK, 

move.packagI 

3.  where  :switch_setting  changes  ■  SET.SWITCH 

The  high  level  view  of  the  incremental  maintenance  process  we  will  use  is  as  follows:  1)  when 
a  package  enters  the  network,  for  each  switch  S  that  is  on  the  route  to  the  package's 
destination  bin,  append  the  package  to  the  sequence  of  package’s  due  at  S,  2)  when  the  right 
conditions  occur  ••  the  package  enters  S  or  becomes  misrouted  before  reaching  S  ••  remove 
the  package  from  S’s  sequence. 

Looking  first  at  CREATE.PACKAGE,  we  loop  ►1  through  the  free  variable  switch  and  add  >2 
the  newly  created  package,  new  to  the  sequence  for  all  switches  meeting  the  criteria. 


p 


ss 

v 


v* 


K  •  '  V1  \ 
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demon  CREATE_PACKAGE( ) 
trigger  RANDOM( ) 
response 
atomic 

create  package.new  1 1 

package. new :  destination  *  4  bin  and 
package.new : located_at  *  the  source ; 

►  j  loop  switch  1 1 

MEMO_LOCATION_BIN(sw/7c/i  package.new:  destination) 
and 

-((package.new:  LOCATEDjtT  •  switch)  asof  everbefore) 
and 

( MEMO_LOCATION_BIN(pac/cape.new :  LOCATED.AT , 
package.new :  destination) 

and 

-3  switch.  2  1 1 

(package.new  :located_at  «  switch.2 
and 

~M£M 0_L0 C  ATION^BI  N  ( switch.2 :  SWITCH_SETTING , 
package.new :  destination  ) ) ) 

►2  do  update  packagesjdue  fif  PACKAGES_DUE_AT_S  WITCH ( switch , S ) 

to  PACKAGES_DUE_AT_SWITCH(sw/fcht*)  concat  <package.new> 
end  atomic; 


Reasoning  that  package.new  cannot  have  been  at  (any)  switch,  that  it  certainly  must  be  on 
the  route  to  its  bin  (unless  a  pipe  is  missing)  and  that  it  is  not  currently  located  at  a  switch 
allows  us  to  simplify  to  the  following: 


demon  CREATE_PACKAGE( ) 
trigger  RANDOM() 
response 
atomic 

create  package.new  1 1 

package. new:  destination  ■  a  bin  and 
package.new: located. at  «  the  source ; 

►3  loop  (switch  || 

MEMO_LOCATION_BIN  (switch ,  package.new:  destination)  ) 
do  update  packages_due  gi  P  ACKAGES_DUE_AT_SWITCH(  switch,  $) 
to  PACKAGES_DUE_AT_S  WITCH  (switch,*)  concat  <package.new> 
ft&d  atomic: 
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|  Method  Global IzsActton  I 

Goal  :  Globalize  A I  action 

Filter:  a)  compon#nt-of[A,  X  |  atomic] 

Action:  1)  Untold  X 

[You  cant  pull  something  out  o  1  an  atomic;  jitter.] 

|  End  Method  I 


STEP  5.1 3:  Unfold  atomic ...  end  atomic 


|  Method  UnfoldAtontc  I 

Goal :  Untold  A|  atomic 

Action:  1)  Show  sequential*  ORDERMG ( 0 1 ordering ,  A) 

2)  Show  SUPERf LUOUS.ATOMIC  (  A  ) 

3)  Apply  UN*OU>-ATOMIC(A.  0) 

[You  can  untold  an  atomic  It  you  can  show  that  thara  exists  soma  valid 
saguantial  ordering  ot  the  statements  and  that  no  demonic  or  Intarancing 
processes  will  be  etlected  ] 

|  End  Method  | 


We  assume  that  the  user  verifies  both  conditions  and  the  atomic  is  replaced  with  a 
scoping.block. 

We  must  now  find  alt  places  where  the  loop  must  be  moved,  i.e.,  ali  demons  which  trigger 
from  the  execution  of  CREATE.PACKAGE.  The  single  location  of  interest  is 
RELEASE_PACKAGE_INTO_NETWORK.  After  moving  the  maintenance  code  to  that 
demon's  response,  we  have  the  following: 
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demon  RELE  ASE.P  AC  K  AGE  JNT0_NET  W 0 R K  ( package. new ) 
tripper  package. new : located. at  ■  iM  source 
response 
beoin 

loop  ( switch 1 1 MEMO  JLOC  ATI0N.BIN (switch , package. new i destination)  ) 
do  update  package$_due  g 1  PACKAGES_DUE_AT_SWITCH(sw/7c/7,$) 
to  PACKAGES_DUE_AT_SWITCH(swrtch,»)  concat  (.package. new> ; 
if  LAST_PACKAGE_DESTIN  ATION ( • )  *  package. new: destination 
then  in.yake  WAIT[] ; 

update  lastjdestination  la  LAST_PACKAGE_DESTINATION($) 
to  package. new :  destination 
update  :locateo.at  al  package.new 

la  (1M  source)  :SOURCE_OUTLET 

MU: 


We  now  have  taken  care  of  CREATE.PACKAGE,  i.e.,  the  initial  increment  of  the  sequences. 
We  now  must  add  code  to  decrement  the  sequences  in  appropriate  cases. 

The  first  step  would  be  to  maintain  the  sequence  in 
RELEASE_PACKAGE_INTO_NETWORK:  the  uwaate  of  the  packages  location  to  the 
source’s  outlet  is  a  relevant  change.  However,  since  there  is  only  one  outlet  pipe  from  the 
source,  we  can  show  that  the  maintenance  code  is  unnecessary.  The  actual  steps  will  be 
similar  to  the  simplification  of  the  maintenance  code  in  CREATE.PACKAGE,  and  will  be 
omitted  here. 

We  will  next  look  at  the  MOVE.PACK  AGE  demon  since  it  updates  the  location  of  a  package, 
and  hence  potentially  can  cause  it  to  become  misrouted  or  located  at  a  switch. 


demon  MOVE_PACKAGE(pac*age) 

trigger  3  location. next  ||  MO VEMENT_CONNECTION ( package :  located.at , 

location. next) 

rj-sponsg 

update  :  located.at  package 

ifi  MO VEMENT_CONNECTI ON ( package :  LOCATED.AT ,  * ) ; 
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demon  MOVE_PACK  AGE  (package) 

tripnar  3  location. next  ||  MOVEMENT_CONNECTION (package :  LOCATED.AT, 

location,  next) 


respond 

atomic 

update  : LOCATED  AT  package 

12  MO  VEMENT.CONNECTION  ( package :  LOCATED.AT .  •  ) ; 

►i  loop  switch  1 1 

-( MEMO_LOCATION.BIN  (sw//ch  package: destination) 
and 

- ( MOVEMENT.CONNECTION  ( package :  LOCATED.AT ,  • )  ■  switch ) 
asof  everbefore) 
and 

( MEMO.LOC  ATION.BIN  { M  O  VEMENT.CON  NECTI  ON  ( 

package :  located.at  ,  • ) . 
package :  destination  ) 
and 

-3  switch. 2  1 1 

( MO  VEMENT.CON  NECTI  ON  ( package :  LOCATED.AT ,  • )  « 

switch.2 


and 

~MEMO_LOCATION.BIN  ( switch.2 :  SWITCH.SETTING . 

package :  destination)  ) ) ) ) 

dp  update  packages  jdue  fll  PACKAGES.DUE.AT.S WITCH  (switch. $) 
12  PACKAGES_DUE_AT_S  WITCH  (switch,*)  minus  <package> 

£od  atomic: 


Our  only  worry  is  if  a  package  moves  into  a  switch;  if  it  moves  to  any  other  type  of  location,  it 
cannot  effect  our  sequence.  When  it  moves  into  a  switch,  we  must  remove  it  from  that  switch 
sequence  and  possibly  others  if  the  switch  is  set  wrong  (because  of  bunching).  Using  a 
number  of  simplification  steps  (omitted  here)  we  arrive  at  the  following: 
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demon  MOVE.PACK  AGE  (pacAage) 

triooar  3  location. next  ||  MOVEMENT-CONNECTION  (package : located.at , 

location.next) 

resoonse 

Atomic 

update  : located. at  at  package 

is.  MOVEMENT  CONNECTION  ( package :  LOCATED  AT ,  •  ) ; 

►,  ±t 

3  switch.current  1 1 

( MO VEMENT.CONNECTION (package : LOCATED. AT .  * )  > 

switch.current 


and 

MEMOJ-OCATION.BIN (switch.current ,  package :  destination  ) ) 

then 

►2  11  MEMO.LOC  ATION_BIN(  sw/fch.currenr :  SWITCH.SETTING , 

package :  destination  ) 

then 

►,  update  packagesjdue  fli  PAC K AGES.DUE.AT_S WITCH ( switch.current ,  S ) 

to  PACK AGES.DUE.AT_S WITCH ( switch.current . • )  minus  package 
►4  else 

►6  loop  ( switch 1 1 MEMO.LOC ATION.BIN ( switch , package : destination ) ) 

do  update  packagesjdue  fil  PACKAGES_DUE_AT_SWITCH(sw/fch,S) 
to  PACK  AGES_DUE_AT_$WITCH  (*w/fch , • )  minus  package ; 
EM  atomic: 

AM 


To  paraphrase,  P 1  if  a  package  is  moved  into  a  switch  and  that  switch  is  on  the  route  to  the 
package’s  destination  then:  *2  if  the  switch  is  set  right  then  f3  remove  the  package  from  the 
sequence  due  at  the  switch,  else  >4  if  the  switch  is  set  wrong  then  P5  remove  the  package 
from  all  switches  along  the  package's  destination  route,  including  the  current  one. 

STEP  5.1 4:  Purity  if ...  J&fin ...  in  MOVE.PACKAGE 

MOVE.PACK AGE  is  outside  of  our  portion  of  the  development,  hence  the  introduced  code 
must  be  moved  in. 
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|  Method  Unfold  Atomic  | 

Goal:  Unfold  A | atomic 

Action:  1)  Show  kquential-o«O€R»<3(0|  ordering ,  A) 

2)  ShOW  8U*WLU0U8_AT0Me(A) 

3)  Apply  unfold- atomc(  A,  0) 

[You  can  unfold  an  atomic  If  you  can  ahow  that  fhora  exists  aoma  valid 
taquantial  ordering  of  the  statements  and  that  no  demonic  or  Infarancing 
processes  will  be  affected, J 

|  End  Method  | 


We  rely  on  the  user  to  verify  the  two  conditions.  The  actual  unfolding  uses  the  following 
transformation: 


atomic 

update  X:a  to  v; 
Expression  using  v> 
end  atomic 

begin 

update  X: a  to  v; 
Expression  using  X:a> 
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daman  MOVE_PACKAGE(pac*ege) 

trigger  3  location.next  ||  MOVEMENT_CONNECTION ( package : located.at . 

location. next) 

response 

begin 

update  : located  at  n£  package 

in  MOVEMENT  CONNECTION  ( package :  LOCATED  AT ,  *  ) ; 

±t 

3  switch.current  |  package :  located. at  >  switch.current 
and 

MEMO_LOCATION_BIN(sw/7ch.currenf ,  package :  destination  ) 
then 

,jf  MEMO.LOC  ATION.BIN  ( switch.current :  SWITCH_setting  , 

package :  destination  ) 

then 

update  packagesjdue  g±  PACK AGES_DUE_AT_SWITCH  ( switch.current ,  S ) 
to  PACKAGES_DUE_AT_SWITCH(sw/fch.currenf ,  • )  minus  package 
else 

loop  {switch\  | MEM 0_L0C ATION_BIN ( switch , package : destination) ) 
do  update  packagesjdue  n£  PACKAGES  DUE  AT_S  WITCH ( switch , S ) 
lfl  PACK AGES_DUE_AT_S  WITCH ( switch , • )  minus  package ; 

nnd; 


The  maintenance  code  is  now  ready  to  be  moved  out  of  MOVE.PACK  AGE.  We  must  find  all 
demons  which  trigger  on  the  update  of  a  package's  location  and  move  the  unpure  code  to 
each.  There  are  four  demons  to  consider: 

□  MISROUTED_PACKAGE_REACHED.BIN 

□  SET_S  WITCH 

□  PACK  AGE.ENTERING.SENSOR 

□  PACKAGE.LEAVING.SENSOR 

We  will  work  on  MISROUTED_PACKAGE_REACHED.BIN  first. 


WAV'.  ■.  1*.  -  .  • 


”7 


I 


S3 


Cl 
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demon  MISROUTED_PACKAGE_REACHED_BIN(peckege,  bin. reached,  bin. intended) 
triooer  package : located.at  ■  bin. reached 
and 

package :  destination  ■  bin. intended 62 

response 

invoke  MISROUTED_ARRIVAL(P/n.reached,  bin.intended) 


After  distributing  the  maintenance  of  PACKAGES_DUE_AT_S  WITCH  ►1  into  the  response  of 
MISROUTEO_PACKAGE_REACHEO.BIN,  we  have  the  following: 


demon  MISROUTED_PACKAGE_REACHED_BIN  (package,  bin.reached,  bin-intended) 
triooer  package : located_at  ■  bin.reached 
and 

package :  destination  ■  bin.intended 

responsB 

begin 


3  switch.current  J  package :  located.at  «  switch.current 

and 

MEMO.LOC ATION_BIN( switch.current ,  package :  destination ) 
then 

it  MEMOJLOCATION_BIN( switch.current :  SWITCH.SETTING , 

package :  destination  ) 

then 

update  packages jdue  at  PACK AGES_DUE_AT_SWITCH ( switch.current , S ) 
to  PACKAGES_DUE_AT_SWITCH(sw/fch.cwrrenf ,•)  minus  package 
else 

loop  (switch \  | MEMO _LOC ATION_BIN (sw/fch , package : destination ) ) 
do  update  packagesjdue  at  PACKAGES  DUE_AT_S WITCH  (switch, $) 
1ft  PACK  AGES_DUE_AT_SWITCH(sw/fch , • )  minus  package ; 
invoke  MISROUTED_ARRIVAL(b/n.reeched,  bin.intended) 
end 


Since  we  know  that  package  is  located  at  a  bin  when  this  demon  triggers,  we  can  simplify 
away  all  of  the  newly  added  code  since  it  relies  on  package  being  located  at  a  switch. 


Next,  we  will  look  at  SET.SWITCH  as  we  have  developed  it  so  far. 


‘Gist  does  net  allow  the  tame  object  to  be  bound  to  asperate  variable*  (aee  section  3). 


I*/-  Vv-  f- vvi 
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demon  SET_S WITCH ( switch ) 
trigger  3  package  1 1 

package  «  li£4l(PACKAGES.DUE_AT.SWITCH(*  switch)) 
and 

SWITCH  JS.EMPTY  ( switch  ) 

response 

fa.fi.fl.iO 

update  : switch_setting  fll  switch  to 
( pipe  ||  pipe  •  switch :  switch.outlet 
and 

MEMO_LOCATION_BIN(p/pe  package :  destination)  ) 

and 


Knowing  that  the  package  cannot  be  located  at  a  switch  when  the  maintenance  code  is 
executed  allows  us  to  employ  a  similar  simplification  process  as  on 
MISROUTED_PACKAGE_REACHED.BIN  in  getting  rid  of  all  of  the  introduced  maintenance 
code  (the  actual  steps  are  omitted  here.). 


The  next  location  of  interest  is  PACKAGE_LEAVING_SENSOR. 


demon  PACKAGE_LEAVING_SENSOR(pacfcage,  sensor) 
trigoer  -package :  located_at  *  sensor 
rfispojsfi  null: 


After  unfolding  the  maintenance  code,  we  have 
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demon  PACKAGE.LEAVING.SENSOR  (package,  sensor) 
trigger  -package : located_at  •  sensor 
Ctlflflflll 

►:  Ji 

3  switch. current  |  package :  LOCATEO.AT  >  switch. current 
and 

MEMO_LOCATION.BIN (switch.current ,  package : destination) 
then 

II  MEMO_LOCATION_BIN(sw/fc/7.eurrenf r SWITCH.SETTINO , 

package :  destination) 

then 

update  packagesjiue  flf  PACK AGES_DUE_AT_SWITCH ( switch. current .  S ) 
to  PACKAGES..DUE_AT_SWITCH(swfte/).currenf  ,•)  minus  package 
else 

loop  {switch  |  |  MEM  O.LOC  ATI  ON_BIN(sw/fch  .package : DESTINATION) ) 
do  update  packagesjiue  fll  PACKAGES_DUE_AT_SWITCH(sw/fc/).S) 
Ifl  PACKAGES  DUE_AT  S WITCH  (switch,*)  minus  package ; 


We  will  return  to  simplify  ►1  after  a  few  more  steps. 


We  have  one  location  remaining  to  look  at,  P  ACKAGE_ENTERlNG_SENSOR . 


demon  PACK AGE_ENTERING_SENSOR (package,  sensor) 
trigoer  package: located«-at  ■  sensor 

rispmfl  null; 
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demon  PACKAGE.ENTERING.SENSOR  (package,  sensor ) 
trigger  package :  located«-at  «  sensor 
response 

►,  H 

3  switch. current  \  package :  located_at  ■  switch. current 
and 

MEMO  _LOCATION_BIN(sw7re/i.curre/7f .  package :  DESTINATION ) 
then 

if  MEMOJ.OC  ATION.BIN  (sw/fch.eurrenf :  SWITCH.SETTING . 

package :  destination  ) 

then 

update  packagesjdue  gf  PACKAGES_DUE_AT_SWITCH(sw/fch.currenf  ,S) 
to  PACKAGES_DUE_AT_SWITCH(sw/fch.currenf,*)  minus  package 
el  se 

loop  (switch 1 1 MEMO.LOC  ATION.BIN  (switch  .package:  destination)  ) 
do  update  packagesjdue  gf.  PACKAGES_DUE_AT_SWITCH(sw/fch,$) 
to  PACK  AGES_DUE_AT_SWITCH  (switch,*)  minus  package ; 


We  have  now  completed  the  distribution  of  maintenance  code  for 
PACKAGES«-DUE*-AT«-S WITCH.  However,  there  are  several  more  optimizations  we  can 
perform.  As  a  preliminary  step,  we  will  break  out  the  supertype  sensor.  In  the  initial 
specification,  the  type  sensor  allowed  several  actions  to  be  localized,  and  hence  improved 
understanding.  However,  as  a  development  progresses,  abstractions  such  as  sensor  tend  to 
get  in  the  way  and  certain  optimizations  are  made  easier  if  they  are  removed.  Such  is  the  case 
here.  The  removal  of  sensor  from  several  demons  will  allow  us  to  further  optimize  the 
maintenance  code  introduced  earlier.  We  will  work  on  PACKAGE_LEAVING_SENSOR  first. 

STEP  5.1 8 fuser):  Casify  PACK AGE_LEAVING_SENSOR 


|  Method  C«s1fySup«rTMgger 

Goaf:  Casify  0 1 demon 
Finer-,  a)  trtggar-of[T,  PJ 

b)  componant-of [S  |  auparlypa ,  T] 
Action  -.  1)  Apply  CAS^Y.D£M0N.80PERTYPE(  T ,  S) 

[Spawn  a  separata  demon  for  every  subtype  X  of  S.] 
|  End  Method 
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We  gain  two  new  demons,  only  the  first  useful  in  the  current  environment63.: 


demon  PACK AGE_LEAVING_SWITCH (package,  switch) 
trigger  -package : located_at  *  switch 
r93P.0n.58 

►»  II 

3  switch. current  \  package: locateo.at  *  switch.current 
and  . . . ; 

demon  PACKAGE_LEAVING.BIN (package,  bin) 
trigger  -package :  located.at  «  bin 
response 
►i  II 

3  switch.current  |  package :  located.at  *  switch.current 
and  . . . 


Since  the  PACKAGE_LEAVING_SWITCH  demon  relies  on  a  package  ogi  residing  at  a 
switch,  the  introduced  code  can  be  simplified  away.  Although  the  second  demon, 
PACKAGE_LEAVING.BIN,  is  never  triggered,  we  can  expect  that  further  elaboration  of  the 
spec  will  change  this.  In  that  case,  we  can  simplify  away  the  code  by  showing  that  the 
package's  location  after  leaving  a  bin  can  never  be  a  switch. 

We  next  look  at  specializing  sensor  in  PACKAGE.ENTERING.SENSOR. 

STEP  5.1 9 fuser):  easily  PACKAGE_ENTERING_SENSOR 


|  Method  CasIfySuperTrlgger  | 

Goal:  easily  D| demon 
Fitter:  a)  tr1gger-of[T,  D] 

b)  compon«nt-of [S  |  supertype ,  T] 

Action:  1)  Apply  CASIFY_DEMON.SUPERTYPe(T,  S) 

[Spawn  a  separata  demon  tor  every  subtype  X  ol  S.J 
|  End  Method  I 
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We  gain  two  new  demons. 


demon  P AC KAGE.ENTERING.S WITCH ( package,  switch) 
triooar  package : LOCATED_AT  ■  switch 
response 
>l  11 

3  switch.current  \  package :  located_at  ■  switch. current 
and 

MEMO_LOCATION_BIN( switch.current,  package:  DESTINATION) 
then 

if  MEMOjLOCATION_BIN{sw/fch.currenf  :SWITCH_SETTING. 

package :  destination  ) 

then 

update  packagesjdue  gf  PACKAGES_DUE_AT_SWITCH(sw/fch.currenf  ,$) 
Ifi  PACKAGES_DUE_AT_SWITCH(sw»fc/>.currenf  ,•)  minus  package 
else 

loop  ( switch |  |  MEMO_LOCATION_BIN(sw/fch  .package : destination)  ) 
do  update  packagesjdue  gf  PACKAGES_DUE_AT_SWITCH(sw/7c/>.S) 
to  PACKAGES_DUE_AT_SWITCH(sw/7ch,*)  minus  package ; 

demon  PACKAGE_ENTERING_BIN( package,  bin) 
tri^oer  package : located. at  «  bin 
reSPflngg 
►,  11 

3  switch.current  \  package :  LOCATED, AT  *  switch.current 
and  . . . 


We  can  get  rid  of  the  maintenance  code  from  PACKAGE_ENTERING_BIN  by  showing  that  a 
package  cannot  be  both  at  a  bin  and  a  switch. 


Finally,  we  can  do  some  minor  simplification  to  PACKAGE_ENTERING_SWITCH. 
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C.6.  Map  Demons 


At  this  point  in  the  development,  there  are  a  number  of  demons  defined  in  our  portion  of  the 
specification: 

1.  RELEASE.PACKAGEJNTO.NETWORK 

2.  PACKAGE_ENTERING_S  WITCH 

3.  PACKAGE_ENTERING.BIN 

4.  PACKAGE_LEAVING_S WITCH 

5.  PACKAGE_LEAVING.BIN 

6.  INIT.MEMO 

7.  SET_S WITCH 

8.  MISROUTEO_PACKAGE.REACHED.BIN 

There  is  nothing  we  can  do  with  the  first  six  since  each  triggers  on  an  external  event  (e.g., 
packages  entering  the  router,  packages  tripping  sensors).  However,  the  remaining  two, 
SET_S WITCH  and  MISROUTED_PACKAGE.REACHED.BIN,  need  to  be  mapped.  We  will 
look  first  at  SET.SWITCH. 

STEP  6.1  fuser):  Map  SET_S WITCH 


demon  SET_S  WITCH  (switch) 
trigger  3  package  | | 

►  j  package  •  firstf PACKAGES  DUE  AT  SWITCHf  switch)) 

and 

►2  S  WITCH  _IS_EMPTY  ( switch  ) 

rft5J0nS.fi 

begin 

update  :SWITCH_SETTING  switch  U 

( pipe  ||  pipe  •  switch : switch.outlet  and 

MEMO_LOCATION.BIN {pipe  package :  DESTINATION) ) 

ftnJ 
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|  Method  CeilfyDemon 

Goa/:  Map  D | demon 
Action :  l)  easily  D 

2)  fora'll  casa*of[X,  0}  do  Map  X 

f  Try  mapping  by  casa  analysis  ] 

|  End  Method 


STEP  6.2:  Casify  SET.SWITCH 

SET.SWITCH  may  trigger  on  either  of  two  events:  a  package  becoming  the  first  in  some 
sequence  due  at  a  switch;  a  switch  becoming  empty.  We  will  split  the  current 
SET_SWITCH  demon  into  separate  ones  to  trigger  on  each  individually.  Note  that  the 
selection  of  the  trigger  splitting  method  here  requires  a  fair  amount  of  insight.  One  has  to 
notice  that  there  are  two  components  of  the  SET_SWITCH  trigger,  one  that  is  under  direct 
mechanical  observation  (a  switch  becoming  empty)  and  one  that  is  not  (a  package  becoming 
the  first  of  an  internal  sequence).  The  former  may  be  handled  by  using  existing  sensing 
information  while  the  latter  will  need  to  be  maintained  explicitly;  two  different  development 
strategies  will  be  required. 


|  Method  CasIfyConjuncttveTrlgger  | 

Goal:  Casify  0|  demon 

Fitter :  «)  g1$t-typt-offT|tr1ggtr-of[0). 

conjunction) 

Action:  1)  Show  moivcum..start(D) 

2)  Apply  8PLrr.CONJUNCTIVl.TWO«B(D,  T) 

[It  may  ba  aaslar  to  break  a  demon  up  Into  special  cases  and  then  trying  to 
map.  Make  sure  that  no  new  triggerings  are  created.] 

|  End  Method  I 
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demon  SET_SWITCH_WHEN_BUBBLE_PACKAGE(sw/fc/)) 
trlooer  3  package  1 1 

package  •  first! PACKAGES  DUE  AT  SWITCH!*  switch)) 

response 

begin 

require  SWITCH_IS_EMPTY(sw/fch)  At  ThisEvent) 
update  : SWITCH.SETTING  g±  switch  to 

( pipe  ||  pipe  •  switch :  switch.outlet  and 

MEMO_LOCATION.BIN  (p/pe  package :  destination)  ) 
end 

demon  SET  SWITCH  ON  EXIT(sw/fch) 
trlooer  S WITCH JS_EMPTY( switch) 

li&a&oaa 

beoin 

reoui  re  { 3  package  \  \ 

package  «  f Irstf PACKAGES  DUE  AT  SWITCH!*  switch)) 
at  ThisEvent) 
update  :  switch_setting  flf  switch  to 

( pipe  |  |  pipe  •  switch :  SWITCH.OUTLET  and 

MEMOJ.OCATION_BIN(p/pe  package :  destination)  ) 
end 


STEP  6.3:  Map  SET.SWITCH.WHEN.BUBBLE.PACKAGE 


|  Method  UnfoldDemon  | 

Goal:  Map  0 1  demon 

Action:  1)  fonll  tr1jg#r-loe«t1on[D,  L.  spec] 
do  Untold  D  it  l 

[To  Map  a  demon,  untold  It  where  appropriate.] 

|  End  Method  | 


We  must  locate  each  place  that  the  trigger  may  change,  i.e.,  that 
PACKAGES_DUE_AT_SWITCH  is  changed.  There  are  two  such  locations: 

1. the  sequence  is  incremented  ►1  when  a  package  enters  the  network 
(RELEASE.PACKAGEJNTO.NETWORK) 

2.  the  sequence  is  decremented  when  a  package  enters  a  switch 
(PACKAGE.ENTERING.SWITCH). 


We  will  look  at  the  former  first: 
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demon  RELEASE_PACKAGEJNTO_NETWORK  (package.new) 
trigger  package. new: located. at  ■  the  source 
response 
begin 

loop  ( switch  1 1 MEMO.LOCATION.BIN ( switch  ,package.new :  destination)  ) 

►  .  i £  update  packagesjdue  SL 1  PACK  AGES.DUE  AT  SWITCH  (switch, $) 

1ft  PACKAGES_DUE_AT_SWITCH(sw/fc/) , • )  concat  <package.new> ; 
if  LAST_PACK AGE_DESTIN ATION ( • )  *  package. new : destination 
then  invoke  WAIT[]; 

update  lastjdestination  in  LAST_PACKAGE_DESTINATION($) 
to  package. new :  destination  ; 
update  :located_at  gf  package. new 
la  (ite  source)  isource.outlet 

fiM; 


STEP  6.4:  Unfold  SET_SWITCH_WHEN_BUBBLE_PACKAGE  at 

►  .  update  packages  due  of  PACKAGES_DUE_AT_SWITCH(sw/fch ,  $) 

Ifl  PACK  AGES_DUE_AT_S  WITCH  (sw//ch ,  •)  concat  <package.new>  ; 


|  Method  ScatterComputationOf Demon  | 

Goal:  Untold  D  |  demon  at  L 
Filtar-.  a)  tMgger-1ocat1on[D,  L.  $] 

Action:  1)  Apply  unfou>.DEMON.COOE(P  L) 

2)  Purity  L 

[To  untold  a  damon  D  at  a  triggar  point,  Vick  in  coda  to  computa  It  and  make 
sura  L  la  within  implamantabla  portion  ot  spec  ] 

|  End  Method  | 


After  adding  the  maintenance  code  >2,  we  have 
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demon  RELEASE_PACK  AGE  JNTO.NET  WO R K ( package. new ) 
triooer  package. new : located_at  ■  the  source 

r$5P8.DSe 

beoin 

loop  ( switch 1 1 MEMOJ-OCATION_BIN(sw/fc/> .package. new: destination) ) 

4 fi 

beoin 

►  .  update  packagesjiue  gf  PACK  A  GES_DUE_AT_S  WITCH  (switch, $) 

to  PACK  AGES_DUE_AT_S  WITCH  (switch,*)  concat  <package.new>; 

►,  II  3  package.  1  1 1 

-( (package.  1  ■  fi  rstf  PACKAGES  DUE  AT_S  WITCH  ( switch  ,•)) 
asof  last  update  gf  PACKAGESJ>UE_AT_SWITCH($w/7c/).S)) 
and 

package.  1  «  f i  rstf  PACKAGES  DUE  AT  SWITCH ( switch . •  ^  i 

then 

begin 

require  SWITCH  JS.EMPTY (switch) 
update  :SWITCH_SETTING  switch  to 

( pipe  ||  pipe  «  switch :  switch_outlet  and 

MEMO_LOCATION.BIN (p/pe”  package.  7 :  DESTINATION) ) 

end 

end 

if  LAST_PACK  AGE_DESTIN ATION  ( • )  *■  package. new :  destination 
then  invoke  WAIT[]: 

update  last  .destination  la  LAST^PACK  AGE.DESTINATION  ( S ) 
to  package. new :  destination 
update  :  located. at  package. new 

to  ( the  source) : SOURCE.OUTLET 


In  general,  the  unfolding  of  a  demon  with  body  B  and  trigger  T  at  event  E  takes  the  following 
form: 

<event  E>  •>  <event  E> 

II  -T  asof  E  m4  T  (now)  then  B 

In  our  case,  E  is  the  update  of  PACKAGES_DUE_AT_SWITCH  and  T  is  the  trigger  of 
SET_SWITCH_WHEN_BUBBLE_PACKAGE. 


Some  fairly  sophisticated  reasoning  is  needed  to  simplify  further: 

1.  We  know  that  this  is  the  sole  location  where  packages  are  added  to  sequences, 
and  hence  package. new  was  not  part  of  the  sequence  in  the  previous  state. 

2.  Given  the  semantics  of  sequence  appending,  we  can  reason  that  the  only  way 
that  the  first  element  of  a  sequence  can  change  on  an  append  is  if  the  sequence 
was  initially  empty. 
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We  require  the  user  to  supply  much  of  the  above  reasoning;  the  system  carries  out  the 
mundane  portions  (see  example  B,  section  E.14): 


demon  RELE ASE.P ACK AGE JNTO.NETWOR K  (package. new ) 
trigger  package. new :LOCATEO_AT  ■  the  source 
response 

begin 

loop  ( switch  1 1  MEM 0_L0C ATI ON_BIN(sw/fc/>, package. new:  destination)  ) 

dfi 

bggin 

update  packages_due  fit.  PACKAGES_DUE_AT_SWITCH(sw/tch.S) 

Ifi  P  ACK  AGES_DUE_AT_S  WITCH  (switch,*)  concat  <package.new>; 

it 

package.new  •  firsts  PACKAGES  DUE  AT  SWITCH (sw/fch.*) ) 
and 

SWITCH  JS.EMPTY  ( switch ) 
then 

update  :SWITCH.SETTING  fit  switch  la 

( pipe  (|  pipe  *  switch:  switch  ..outlet  and 

MEMO_LOCATION_BIN(p/pe  package.new :  destination  ) ) 

end 

jl  LAST_PACK AGE_DESTlNATION( • )  *  package.new: destination 
then  invoke  WAIT[]; 

update  fast.destination  ia  LAST  J> ACK AGE.DESTIN ATION(S) 
la  package. new:  DESTINATION 
update  jlocated.at  al  package.new 

to  (the  source)  :SOURCE_outlet 


find; 


We  will  look  next  at  PACK  AGE_ENTERING_SWITCH. 


C.6  Map  Demons 
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demon  PACK  AGE_ENTERING_SWITCH(  package,  switch) 
trigger  package : located.at  ■  switch 
response 
li 

MEMO_LOC ATION_BIN ( switch ,  package :  DESTINATION) 
then 

jf  MEMO_LOCATION_B1N{sw/fch :  SWITCH.SETTING, 

package :  destination  ) 

then 

►.  update  packagesjdue  gi  PACKAGES_DUE_AT_SWITCH(sw/'fch,S) 

to  PACKAGES_DUE_AT_SWITCH(sw/fch,*)  minus  package 
else 

loop  ( switch.  1 1 1 MEMO_LOCATION.BIN ( switch.  1 , 

package :  destination  ) ) 

►  2  dp  update  packages  due  PACKAGES  DUE  AT  SWITCH  (sw/fch.  7 ,$) 

PACK  AGES_DUE_AT_SWITCH  (sw/fch. 7 ,  • )  minus  package ; 


Before  preceding,  we  will  factor  the  two  updates  of  PACKAGES_DUE_AT_SWITCH  act,>2 
into  an  procedure  ►g  for  the  sake  of  conciseness. 


STEP  6.5 (user):  Factor 

update  packages.due  flf  PACK AGES_DUE_ AT_S WITCH (  # switch** ,  S) 
to  PACKAGES  DUE_AT_SWITCH(  # switch,9)  minus  xr package 
in  PACKAGE.ENTERING.SWITCH 


|  Method  FactorDBMtlntensncf IntoAction  I 

Goa/:  Factor  U | db-maintenance  In  L 

Action:  1)  Apply  C«EATi_pqoCEDURE_rROM.Tf mplate ( U  A) 

2)  forali  pattarn-matchfu,  W.  L] 

do  Apply  replace.D8maintenac£.with_act)0n(Ii/  A) 

ICraata  a  naw  procedure  A  and  than  tind all  matches  Win  L  and  replace  each 
with  a  call  to  the  new  procedure  A.] 

|  End  Method  I 


fU 

In  a  factor  template,  stype.name  signifies  a  formal  parameter.  The  *  will  be  removed  in  the  procedure 
definition. 
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demon  PACK  AGE_ENTERING_SWITCH  (package,  switch) 
triooer  package : located.at  ■  switch 
response 
II 

MEMOJ-OCATION_BIN(sw/fc/i ,  package : DESTINATION) 
then 

it  MEMO_LOCATION.BIN (  switch :  SWITCH.SETTING . 

package :  destination  ) 

then 

invoice  TRIM_PACKAGES_DUE_AT_S  WITCH  (package,  switch ) 
el  se 

loop  ( switch.  1 1  | MEMO_LOCATION_BIN (switch.  1 , 

package :  destination  ) ) 

invoke  TRIM_PACKAGES_DUE_AT_SWITCH(paekage .  switch.1) 


►  ,  procedure  TRIM  PACKAGES  DUE  AT_SWITCH (package,  switch) 

update  packagesjdue  fii  PACKAGES_DUE_AT_SWITCH(sw/tch.S) 
PACKAGES_DUE_AT_SWITCH(sw/fe/i , • )  minus  package : 


Now  unfoldina  the  maintenance  code 


for  SET.SWITCH.WHEN.BUBBLE.PACKAGE 


demon  PACKAGE.ENTERING.S  WITCH  (package,  switch) 
triooer  package : located.at  ■  switch 
response 
it 

MEMOJ.OCATION_BIN($w/7c/>,  package : DESTINATION) 
then 

if  MEMO_LOCATION_BIN(sw/fC/J :  S WITCH.SETTING , 

package :  destination) 

then  invoke  TRIM_PACKAGES_DUE_AT_SWITCH(packape. 

switch.current) 

else 

loop  (switch\  | MEMO  LOCATION  BIN ( switch , package : destination ) ) 
invoke  TRIM_PACKAGES_DUE_AT_SWITCH {package,  switch ); 


procedure  TRIM_P  ACKAGES_DUE_AT_S  WITCH  (package,  switch) 
begin 

update  packagesjlue  fli  PACKAGES_DUE_AT_SWITCH(sw/fc/),$) 
to  PACKAGES  DUE  AT  SWITCH(sw/fc/>,*)  minus  package ; 

►4  il 

3  package.  1  |  | 

-((package.;  «  f  i  rstf  PACKAGES  DUE  AT  SWITCH  ( switch  ,*)) 
asof  last  update  gf  PACKAGESj)UE_AT_SWITCH(sw/fc/j.  S)) 


package.  1  -  Ii£it(PACKAGES>DUE_AT_SWITCH(sw/7c/i,*)) 

then 

begin 

require  S  W  ITCH  _l  S_EM  PT  Y  ( switch ) 
update  : switch^setting  fll  switch  jp 

( pipe  ||  pipe  •  switch :  switch_outlet  and 

MEMO_LOCATION.BIN {pipe ,  package. 7 : destination)  ) 


end 


end 


Note  that  the  factoring  was  a  mixed  blessing.  While  it  did  allow  us  to  unfold  in  a  single  place,  it 
prevents  us  from  carrying  out  some  further  optimization:  if  the  procedure  is  being  called  when 
the  switch  is  set  right,  we  can  safely  ignore  the  switch  setting  code  (we  can  show  that  the 
switch  is  non-empty).  To  actually  get  rid  of  this  unneeded  case,  we  will  eventually  have  to 
unfold  the  procedure  back  into  the  demon  and  simplify. 


We  can  simplify  the  procedure  further  if  we  rely  on  the  user  to  supply  the  following  necessary 
reasoning  step:  the  only  way  for  a  new  package  to  become  the  first  of  the  sequence  is  by  the 
removal  of  the  head  of  the  sequence. 
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procedure  TRIM_PACKAGES_DUE_AT_SWITCH(pacAage,  switch) 
beg  i  n 

If  first  (PACK  AGES  DUE  AT  SWITCH  ( switch .  •)  «  package 
then 
begin 

update  packages jdue  at  PACKAGES.DUE.AT.SWITCH  (switch ,$) 
to  PACKAGES_DUE_AT_SWITCH(switcb,*)  minus  package ; 
begin 

require  SWITCH_IS_EMPTY( switch) 
update  :  switch.SETTING  jjf  switch  £a 

( pipe  ||  pipe  •  switch : switch.outlet  and 
MEMO  LOCATION  BIN(pipe, 

firstf PACK  AGES_DUE_AT_SWITCH(  switch .  •) 

):  DESTINATION)) 
end 

end 

else 

update  packages  jdue  at  PACKAGES.DUE.AT.SWITCH  (switch ,  S ) 
to  PACKAGES.DUE.AT.SWITCH  (switch,*)  minus  package ; 

end 


This  takes  care  of  the  SET_SWITCH_WHEN.BUBBLE.PACK  AGE  demon  which  deals  with 
the  package  sequence  changing.  We  now  must  take  care  of  setting  a  switch  when  it  becomes 
empty,  an  event  captured  by  the  SET_SWITCH.ON.EX IT  demon. 


demon  SET.SWITCH.ON.EX  IT  (switch) 
trigger  SWITCHJS.EMPTY  (switch) 

r.I5J0nSLfl 

begin 

rmuire  (3  package  1 1 

package  »  tim(PACKAGES_DUE_AT_SWITCH(*  switch)) 
at  ThisEvent) 
update  :  switch.setting  at  switch  £g 

( pipe  ||  pipe  ■  switch :  switch.outlet  and 

MEMO_LOCATION.BIN  (pipe  package :  destination)  ) 
end 


C.6  Map  Demons 
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we  will  attempt  to  consolidate  it  with  an  already  existing  demon, 
PACKAGE  LEAVING_S WITCH. 


demon  PACK  AGE_LEAVING_SWITCH  (package,  switch) 

►  j  triooer  -package : located_at  »  switch 

response  null : 

demon  SET_S WITCH_ON_EX IT ( switch ) 

►  2  triooer  S WITCH JS.EMPTY (switch) 

££Mim 

begin 

require  ( 3  package  1 1 

package  *  fi££i(PACKAGES_DUE_AT_SWITCH(*  switch)) 
at  ThisEvent) 
update  : SWITCH.SETTING  fit  switch  to 

( pipe  ||  pipe  ■  switch :  switch  outlet  and 

MEMO_LOCATION.BIN (pipe  package :  destination)  ) 

end 

►  3  relation  SWITCH  JS.EMPTY  (SWITCH) 

definition  not  exists  package  1 1  package :  located_at  *  switch ; 


|  Method  MapByConsol Idatlon 
Goa/:  Map  D  | demon 

Filter:  a)  pattern-match[d»mon ,  D2,  spec] 
b)  0  »  D2 

Action :  1)  Consolidate  D-and  D2 

[ To  map  D.  Und  some  other  demon  D2  and  consolidate.] 

|  End  Method 


Naturally,  the  selection  of  the  right  demon  to  consolidate  with  is  crucial. 


STEP  6.7:  Consolidate  SETSWITCHON  EXIT  and  PACKAGE  LEAVING  SWITCH 
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|  Method  MergeDemon*  I 

Goa/ :  Consolidate  01  \  demon  and  D2| demon 
Action:  1)  Equivalence  trtgger-of [Dl]  and 

trtgger-of[D2] 

2)  Equivalence  var-dac1aratton-of[Dl]  and 

var-dec1arat1on-of[D2] 

3)  Show  mergeable_demons(D1.  D2,  1 1  ordering) 

4)  Apply  demon_meroe(D1  ,  D2  ,  I) 

[ You  can  consolidate  two  demons  k  you  can  show  that  they  have  the  seme 
local  variables,  the  same  triggering  pattern  and  that  they  meet  certain 
merging  conditions.] 

|  End  Method  I 


STEP  6.8:  Equivalence 

►  trigger  -package:  located_at  *  switch 

►2  triooer  SWITCHJS_EMPTY(sw/fch) 

As  in  step  2.3,  we  will  anchor  the  first  trigger  and  try  to  reformulate  the  second. 


|  Method  Anchorl 

Goal  :  Equivalence  X  and  Y 
Action:  1)  Reformulate  Y  as  X 

[ Try  changing  the  second  construct  into  something  that  matches  the  first.] 

|  End  Method 


C.6  Map  Demons 
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|  Method  ReformulateOerlvedRelatlon 

Goal:  Reformulate  RR  |  relation-reference  at  X 

Filter:  a)  gist-typa-ofInama-of[R,  RR], 
derived- relation] 

Action:  1)  Unfold  R  at  RR 

1 

/T ry  reformulating  the  body  as  X.] 

|  End  Method 

1 

STEP  6.10:  Unfold  ►,  SWITCHJS.EMPTY  at  reference 

|  Method  ScatttrComputatlonOfDarlvedRelatlon 

Goal:  Untold  DR  |  derived-relation  it  L 
Filter:  a)  rafaranc#*1ocatton[DR.  L.  S] 

Action:  1)  Apply  UNf OLO^cOMPUTATiON.COOe  ( DR  L) 

2)  Purity  L 

/To  untold  a  derived  relation  DP  at  a  reference  point,  stick  In  code  to  compute 
it  and  make  sure  L  Is  within  implementable  portion  of  spec.] 

|  End  Method 


The  unfolding  of  SWITCHJS.EMPTY  still  does  not  achieve  the  reformulation  goal  in  step 
6.9,  hence  it  is  reposted: 


STEP  6.11  (reposted):  Reformulate 

tripper  -3  package. 0  ||  package. 0: located_at 
as  tripper  -package : located_at  ■  switch 


switch 


Our  goal  here  is  to  produce  a  more  general  trigger  for  SW1TCHHS*- EMPTY  than  its  current 
one.  That  is,  we  want  to  trigger  whenever  a  package  is  no  longer  located  at  a  switch  no  matter 
if  a  new  package  has  moved  into  the  switch  or  not.  The  current  trigger  requires  that  a 
package  leave  a  switch  aq£  that  no  other  switch  moves  in  immediately  behind  it. 
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|  Method  Ref ormulateExI stent lal Trigger  | 

Goal:  Reformulate  Tltrlooer  -3  o||R(o)  as  R(o') 

Action:  1)  Show  TniooER.oeNeR*uZAaLE(T) 

2)  Apply  OENeRALIZE.TRlOOCR(T) 

[You  can  raformulata  an  existential  trigger  Into  a  universally  quantified  one 
under  certain  conditions .] 

|  End  Method  | 


We  assume  the  user  verifies  that  the  trigger  is  generalizable.  After  application  of 
GENERALIZE.TRIGGER,  we  have 


demon  PACK  AGE_LEAVING_S WITCH  (package,  switch) 

►  j  trigger  -package : located.at  ■  switch 
response  null : 

demon  SET_SWITCH_ON_EXIT(pac*age.gen.  switch) 

►2  trigger  -package. gen : LOCATEO.AT  «  switch 
response 

if  -3  package  \  \ package :  LOCATED.AT  »  switch 
then  begin 

reouire  ( 3  package  | | 

package  •  firstf  PACKAGES  DUE  AT  SWITCH (•  switch)) 
at  ThisEvent) 

update  :Switch_setting  fil  switch 

( pipe  ||  pipe  ■  switch : switch.outlet  and 

MEMO_LOCATION.BIN (p/pe  package :  DESTINATION ) ) 

end 
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demon  PACK  AGE_LEA  VING_S  WITCH  (pacfcage.gen,  switch) 
trigger  -package. gen: located. at  ■  switch 
response 

if  ~3  package j  | package :located_at  ■  switch 
Itian.  begin 

require  ( 3  package  | | 

package  «  ii£&i(  PACKAGES_DUE_AT_SWITCH(*  switch)) 

at  ThisEvent) 

update  :SWITCH_SETTING  fil  switch  to 

( pipe  ||  pipe  •  switch :  SWITCH.OUTLET  and 

MEMO_LOCATION.BIN (pipe  package :  destination)  ) 

end 


This  finishes  our  task  of  mapping  away  SET_S WITCH. 


STEP  6.1 3 fuser):  Map  MISROUTED.PACK  AGE_REACHED.BIN 


demon  MISROUTED_PACKAGE_REACHED_BIN(pacfcage,  bin. reached,  bin.intended) 
trigger  package : located.at  «  bin. reached 
And 

package :  destination  «  bin.intended 
response  invoke  MISROUTED.ARRIVAL (bin.reached.  bin.intended) 


|  Method  CaalfyDemon  | 

Goa/:  Map  D | demon 
Action:  1)  Casity  D 

2)  forall  casa-of[x,  D]  do  Map  X 

[ Try  mapping  by  case  analysis.] 

|  End  Method  | 


STEP  6.14:  Casify  MISROUTED_PACKAGE.REACHED.BIN 


We  will  use  the  same  trigger  splitting  strategy  as  used  on  SET_S WITCH  in  the  previous 
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section.  MISROUTED_PACKAGE_REACHED.BIN  may  trigger  on  either  of  two  events:  a 
package  becoming  located  at  a  bin;  a  package’s  destination  being  set.  The  selection  of  the 
trigger  splitting  method  here  requires  the  same  insight  as  in  the  SET.SWITCH  case:  one  has 
to  notice  that  one  of  the  two  components  of  the  trigger  is  under  direct  mechanical  observation 
(a  switch  entering  a  bin)  and  one  is  not  (a  package's  destination  changing). 


|  Method  Cat iryConjunetlvaTrlggar  | 

Goal:  easily  D | demon 

Fitter :  a)  gtst-type-of[T|tr1gg§r-of[D]. 

conjunction ) 

Action :  1)  Show  inoivou*i.stabt(D) 

2)  Apply  SPirr_coNjuNCTive.TeiOQCR(D.  T) 

I II  may  be  aasiar  to  break  a  demon  up  Into  spacial  cases  and  than  trying  to 
map.  Make  sura  that  no  naw  triggarings  ara  craatad.] 

|  End  Method  | 


Two  new  demons  are  spawned: 


demon  MISROUTED_P  ACKAGE_LOC  ATED_AT.BIN  ( package, bin. reached, bin-intended) 
triaoer  package : located.at  «  bin. reached 
response 
begin 

reoui re  (package: destination  «  bin.intended 
at  ThisEvent ) ; 

invoke  MISROUTED_ARRIVAL( bin. reached,  bin.intended) 

SM: 

demon  MISROUTED_PACKAGE_DESTINATION_SET(packape,b/n.reached,b/n-/nfended) 
trigger  package : destination  «  bin.intended 
tS.iS.9Hl£ 
begin 

require  (package: LOCATED.AT  «  bin. reached 
at  ThisEvent) ; 

invoke  MISROUTED_ARRIVAL(b/n.reec/)ed,  bin.intended) 

find; 


STEP  6.1 5:  Map  MISROUTED.PACK  AGE.LOCATED.AT.BIN 
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|  Method  MapByConsol Idation  | 

Goa/:  Map  D | demon 

Filter:  a)  pattarn-mateh[damon.  02,  spoc] 
b)  D  *  02 

Action:  1)  Consolidate  0  and  02 

f  To  map  D,  find  soma  other  demon  D2  and  consolidate.) 

|  End  Mathod  | 


STEP  6.1 6:  Consolidate  Ml  S  RO  U  TE  D_P  AC  K  A GE_LOC ATED_ AT_BIN  and 

PACKAGE_ENTERING.BIN 


demon  PACK AGE_ENTER1NG_BIN( package,  bin) 
trigger  package : locateo.at  ■  bin 
response  null: 


|  Method  MergeDemons  I 

Goal:  Consolidate  Dl|  demon  and  02 1  demon 
Action:  1}  Equivalence  trigger-of [01]  and 

tr1gger-of[D2] 

2)  Equivalence  var-dec1arat1on-of[01]  and 

var-dedarat1on-of[D2] 

3)  Show  mepoe*bie.demons(D1,  02.  I  \  ordering) 

4)  Apply  DEMON.MCftOE(Dl,  02,  I) 

[You  can  consolidate  two  demons  II  you  can  show  that  they  have  the  same 
local  variables,  the  same  triggering  pattern  and  that  they  meet  certain 
merging  conditions.) 

|  End  Method  I 


STEP  6.17:  Equivalence  (package,  bin. reached,  bin.intended)  and  (package ,  bin) 
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|  Method  Equ1valancaCompoundStructure*2  | 

Goal:  Equivalence  SI  |  compound~ttructura  and 
S2 1  compound-alructura 

Filter :  a)  plat-typa-ofl*.  Si)  »  Blst-typa-ofl*.  S2] 

b)  -f  1xad-structura[Sl] 

c)  componant-corra*pondenct[Sl.  S2,  C  |  correspondence] 
Action:  1)  fora'll  corraspondanea-pa1ri[C.  Cl,  C2] 

Equivalence  Cl  and  C2 

{Divida-and-conquar:  maka  tha  componantt  ot  two  non-tixad  structures 
equivalent.) 

|  End  Mathod  | 


Choosing  the  correct  correspondence  here  is  a  little  tricky.  Being  of  the  same  type,  the  two 
package  variables  are  paired-off.  However,  bin  can  be  paired  with  either  bin.reached  or 
bin. intended.  We  note  that  both  bin  and  bin.reached  occur  in  their  respective  triggers  and  use 
this  clue  to  make  the  right  choice. 

STEP  6.18:  Equivalence  bin.reached  anti  bin 

As  in  step  2.10,  we  will  eventually  anchor  the  first  and  then  rename. 

Our  equivalence  goal  from  step  6.17  is  still  not  achieved  and  hence  is  reposted. 

STEP  6.1 9  (reposted):  Equivalence  (package .  bin.reached,  bin.intended)  and  (package , 
bin.reached) 

Reapplying  EquivalenceCompoundStructures2  now  will  gain  us  nothing.  We  try  a  new 
method. 
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We  must  locate  each  place  that  a  package’s  destination  is  changed.  The  single  such  location 
is  at  CREATE.PACKAGE. 


demon  CREATE_PACKAGE( ) 
triooer  RANDOM () 

response 

steipic 

create  pack  age.  new  1 1 

package. new: destination  ■  &  bin  and 
package. new: located.at  «  the  source ; 


STEP  6.21:  Unfold  MISROUTED.PACK  AGE_DESTINATION_SET  at 

create  package. new  1 1 
package. new :  destination  ■  a  bin  and 
package. new : located. at  ■  the  source; 


|  Method  Sea tterComput at ionOf Demon  | 

Goal:  Untold  D|  demon  at  L 

Filtar :  a)  trlgger-locatlonJD.  L,  S] 

Action  :  1)  Apply  UNF0LD_0EM0n_C0P£(  D  L) 

2)  Purity  l 

r To  unfold  a  damon  D  at  a  trlggar  point,  stick  in  coda  to  compute  It  and  make 
sura  L  Is  within  implementable  portion  ot  spec.] 

|  End  Method  | 


After  adding  the  maintenance  code,  we  have 


demon  CREATE_PACKAGE( ) 
triooer  RANDOM () 
response 
beoin 
atomic 

create  package. new  |  j 

package. new: destination  «  fl  bin  and 
package. new :  located.at  «  the  source ; 
fiM  atomic 

if  3  bin. intended ,  bin. reached  || 

~( (package. new •.  destination  «  bin.intended) 

asof  last  update  of  package. new: destination) 
and 

package. new:  destination  ■  bin.intended 

then 

reoui  re  package. new :located_at  ■  bin.reached ; 
invoke  MISROUTED_ARRIVAL (D/n. reached,  bin.intended) 


WO 
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C.7.  Termination  State 

This  ends  our  development  of  the  package  router.  The  state  of  the  router  at  this  point  is  given, 
below.  The  Gist/TI  group  is  currently  working  on  an  intermediate-level  language  called  WILL 
which  is  able  to  implement  directly  this  form  of  program. 

Portions  which  have  not  changed  from  the  initial  spec  given  in  Appendix  A  are: 

□  type  hierarchy,  including  attributes  (sensor  could  be  removed  since  It  is  no  longer 
referenced) 

□  constraints 

*  MORE_THAN_ONE_SOURCE 

*  PIPE_EMERGES_FROM_UNIQUE_SWITCH_OR.BIN 

*  UNIQUE_PIPE_LEADS_TO.SWITCH.OR_BIN 

*  SOURCE_ON_ROUTE_TO_ALL_BINS 

□  relations 

*  MISROUTED 

*  SWITCHJS.EMPTY 

□  demons 

*  CREATE.PACKAGE 

*  MOVE.PACKAGE 

□  procedure 

*  MISROUTED_ ARRIVAL 

Portions  of  the  specification  which  are  new  or  have  changed  are  given  below. 
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demon  RELEASE.PACKAGEJNTO.NETWORK (package. new) 
trigger  package. new : located.at  «  the  source 


response 

beoin 

loop  ( switch  |  |  MEMO_LOCATION_BIN(  switch  .package. new :  destination)  ) 
begin 

update  packages_due  P AC KAGES_DUE_AT_SWITCH( switch, $) 
to  PACKAGES_DUE_AT_SWITCH(sw/'fch,*)  concat  <package.new> ; 

it 

package.new  *  f  i rsti  PACKAGES  DUE  AT  S WITCH l switch.  *)) 
and 

SWITCH  JS.EMPTY  (switch ) 
then 

update  :  SWITCH.SETTING  switch  Ifi 

( pipe  ||  pipe  *  switch :  switch_outlet  and 

MEMOJ-OCATION_BIN(p/'pe  package. new : destination ) ) 

end 

if  LAST_PACKAGE_DESTINATION(  •)  *  package.new : destination 
then  invoke  WAIT[]; 

update  las1_deslination  ia  LAST_PACKAGE_DESTIN ATION ( $ ) 
to  package.new :  destination 
update  :  located, AT  package.new 

ifi  (1M  source)  :SOURCE_OUTLET 


find: 


demon  PACKAGEJENTERING_SWITCH(package,  switch) 
trigger  package : LOCATED.AT  «  switch 

resaonse 

it 

MEMO.LOC  ATION.BIN  ( switch ,  package :  destination ) 
then 

it  MEMO _LOC ATION^BIN ( switch :  SWITCH.SETTING , 

package :  destination  ) 

then  invoke  TRIM_PACKAGES_DUE_AT_S  WITCH ( package , 

switch.current) 

el  se 

loop  {switch 1 1 MEMO_LOCATION.BIN (switch, package: destination)) 
dfi  invoke  TRIM_PACKAGES_DUE_AT_SWITCH(  package,  switch)-. 


procedure  TRIM_PACKAGES_DUE_AT_SWlTCH(pac*ape ,  switch) 
begin 

Ii  first  (PACK  AGES  DUE  AT  SWITCH  t  switch .  •)  ■  package 
then 
bep  i  n 

update  packagesjdue  PACKAGES  DUE_AT  SWITCH($w/fc/),S) 
Ifi  PACK AGES_DUE_AT_SWITCH (skv/fch , • )  minus  package ; 
bep  in 

require  SWITCH_IS_EMPTY(sw/fcb) 
update  :  SWITCH.SETTING  q1  switch 

( pipe  ||  pipe  •  switch :  SW1TCH_0UTLET  and 
MEMO  LOCATION  BIN(p/pe, 

f  i  rst(  PACK  AGES  DUE  AT  SWITCH  ( switch .  •) 

):  DESTINATION)) 
end 
end 
else 

update  packagesjiue  q±  PACKAGES_DUE_AT_SWITCH(sw/fch ,S) 
to  PACKAGES_DUE_AT_SWITCH(siv/fch,*)  minus  package ; 
end 


demon  PACKAGE_LEAVING_SWITCH (package. gen,  switch) 
triooer  -package. gen :  located.at  ■  switch 
fC-LPpnse 

if  ~3  package 1 1 package : located.at  «  switch 
then  beoin 

reaui re  ( 3  package  | | 

package  «  f i rstf PACKAGES  DUE  AT  SWITCHf  switch)) 
H  ThisEvent) 
update  :  switch.SETTING  Si  switch  ££ 

( pipe  ||  pipe  «  switch :  SWiTCH_0UTLET  and 

MEMO_LOCATIONJBIN{pipe  package :  destination)  ) 


end 
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demon  PACKAGE_ENTERING_BIN(pae/cage,  bin. reached,  bin.intended) 
trigoer  package : located.at  ■  bin.reached ; 
response 
begin 

reoui  re  ( package : destination  *  bin.intended 
li  ThisEvent); 

invoke  MISROUTED_ARRIVAL(0/n.reacfted,  bin.intended ) 
end : 


demon  PACKAGE_LEAVING.BIN  (package,  bin ) 
trigger  -package :  LOCATED. AT  *  bin 
response  nul  l : 


relation  LAST_PACKAGE_DESTINATION(/asf_desf/naf/on |  bin); 

relation  PACKAGES  DUE  AT  SWITCH  (packages  due  [sequence  of  package, 

switch ) ; 

relation  MEMO_LOCATION_BIN {location,  bin); 


relation  MEMO_LOCATION_BIN (location,  bin); 

demon  INITIALI2E_MEM0_L0CATI0N.BIN ( ) 
trigoer:  ( start  initialization _st ate) 

response 

begin 

loop  6  |  BIN  insert  MEMO_LOCATION_BIN(B,  B) ; 
loop  L  |  LOCATION  1 1 

MEMO_LOCATION_BIN(L.  B)  Md 
L  ■  L2  :  CONNECTION_TO_SWITCH_OR.BIN 
dfi  insert  MEMO.LOCATION.BIN (L2,  B) ; 
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Appendix  D 

Method  Selection  Overlay 

This  appendix  presents  the  selection  information  used  to  produce  the  router  development  in 
appendix  C.  When  overlayed  with  the  development,  the  complete  problem  solving  trace  is 
explicated.  The  sectioning  follows  that  of  C.  Each  step  here  has  the  following  form: 

Step  i.j:  abbreviated  development  goal 

Candidate  Set 
[<augmented  method>]° 

>  General  Rules:  [<general  selection  rule>]° 

>  Method  Specific  Rules:  [<method  specific  rule>]° 

>  Resource  Rules:  ^resource  rule>]° 

>  Ordering  Rules:  [<ordering  rule>]° 

Method  Ordering:  [<ordered  method  list>]° 

>  Action  Ordering  Rules:  [<action  ordering  rule>]° 

Comment:  Optional  comments  on  interesting  problem 
solving  features  of  the  step. 

An  Augmented  method>  under  the  Candidate  Set  has  the  following  form: 

(Abrev:]  MethodName  [(<opinion>  SelectionRule)]0 
An  <opinion>  is  either  a  signed  weight  in  the  case  where  SelectionRule  is  a  non-ordering  rule 
or  an  ordering  operator  (i.e.  >,<)  for  ordering  rules.  In  the  latter  case,  (<  Foo)  says  that  the 
current  method  has  been  ordered  after  some  other  method  or  set  of  methods  by  selection  rule 
Foo.  To  find  the  method  or  meohds  which  are  ordered  before  this  method,  look  for  the 
corresponding  (>  Foo). 

If  a  candidate  method  contains  unbound  free  varaibles,  then  a  breakout  of  all  instantiated 
bindings  is  given  under  the  MethodName  (see  for  example,  step  1.2).  Each  instantiation  has 
the  following  form: 
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[Abrev:1  Binding  [(<Gpinion>  SelectionRule)]0 
Note  that  opinions  expressed  about  the  general  MethodName  are  inherited  by  any  of  its 
particular  bound  instantiaions. 


A  list  of  the  selection  rules  augmenting  the  candidate  set  is  brokenout  by  type  below  the 
Candidate  Set.  This  is  redudant  information  provided  for  convenience. 

Finally,  <ordered  method  !ist>  is  a  partial  ordering  of  the  Candidate  Set  with  the  following 
form: 

Method  Set1(Sum),..MethodSetn(Sum) 

A  MethodSet  is  either  a  1)  single  method  or  2)  a  group  of  MethodSets  from  the  Candidate  Set. 
In  the  second  case,  the  set  is  marked  off  by  set  brackets  ({  }).  After  each  single  method  is  the 
sum  of  all  weights  provided  by  the  selection  rules.  If  no  weight-giving  rules  fired  then  a  dash 
appears  in  place  of  the  sum.  If  MethodSet  occurs  before  MethodSet^  in  the  list  then  all 
methods  in  MethodSet.  are  rated  more  highly  than  all  methods  of  MethodSet.  Methods  within 
a  MethodSet  have  the  same  rating. 

Not  all  methods  of  the  Candidate  Set  may  appear  in  the  ordering  list.  If  a  method’s  weighted 
sum  is  below  a  certain  threshold,  1  currently,  it  will  not  appear.  Also,  if  method  Ml  is  ordered 
by  a  selection  rule  after  method  M2  whose  sum  is  below  the  theshold,  Ml  will  not  appear,  no 
matter  what  its  sum  is.  Currently,  methods  which  have  no  ordering  information  associated 
with  them  are  included  last  in  the  list. 

Bold  facing  is  used  in  the  <method  order  list>  to  mark  the  method  actually  chosen  in  the 
router  development.  Bo'd  faced  methods  which  do  not  appear  first  in  the  list  represent 
locations  where  one  or  more  alternative  methods  were  rated  more  highly  thatn  the  method 
finally  chosen. 

The  details  of  the  Glitter  selection  engine  are  discussed  more  fully  in  chapter  7. 
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D.l.  Remove  PACKAGES_EVER_AT_SOURCE 

Step  1.1  :{user)  Remove  peas  (packages.ever.at.source)  from  spec 

Candidate  Set 

□  RR:  RemoveRelation  ( +  2  BurnedOutHulk)  ( 4-  2  ’RemoveRelationl) 

>  Central  Rules  BurnedOutHulk 

>  Method  Specific  Rules:  ’RemoveRelationl 
Method  Ordering:  RR(*4) 

Step  1.2:  Remove  reference  to  peas  from  spec 

Candidate  Set 

□  BabyWithBathWater 

*  BWBWi:  Y  bound  to  relative-retrieval  (-2  *BabyWithBathWater3) 

*  BWBW2:  Y  bound  to  derived-object  (-2  ’BabyWithBathWater3) 

*  BWBW3:  Y  bound  to  conditional (0  ‘BabyWithBathWaterl) 

*  BWBW4:  Y  bound  to  demon  (-1  ’BabyWithBathWater2) 

□  MegaMove  { 4  i  Filtln)  (>  RemoveRef  1} 

*  MMi :  Y  bound  to  relative-retrieval  { ♦  2  *MegaMovel)  (<  RemoveRe»2) 

*  MM2:  Y  bound  to  derived-object  ( +  2  *MegaMovei)  (>  RemoveRef2) 

□  PositionalMegaMove  (  + 1  Fillln)  (<  RemoveRef  1) 

*  PMMl :  Y  bound  to  relative-retrieval  ( + 1  ’PositionalMegaMove)  (<  RemoveRef3) 

*  PMM2:  Y  bound  to  derived-object  { 4 1  ’PositionalMegaMove)  (>  RemoveRef3) 

□  RemoveByObjectizingContext 

’  RBOCl :  Y  bound  to  relative-retrieval 

*  RBOC2:  Y  bound  to  derived-object 

>  General  Rules.  Fillln 

>  Method  Specific  Rules:  ’BabyWithBathWater,  ’MegaMovel,  ’PositionalMegaMove 

>  Ordering  Rules:  RemoveRef  1,  RemoveRef 2,  RemoveRefS 

Method  Ordering:  MM2( 4 3),  MM1( 4 3),  PMM2(  4  2),  PMM1( 4 2),  (RBOCl(-),  RBOC2(-)} 


Step  1.3:  Isolate  derived  object 
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Candidate  Set 

□  FGIR:  FoldGenericIntoRelation  (4  2  ‘FoldGenericIntoRelation) 

>  Method  Specific  Rutty.  ‘FoldGenericIntoRelation 
Method  Ordering:  FGIR(4  2) 

Step  1.4:  Globalize  derived  object 

Candidate  Set 

□  GDO:  GlobalizeDerivedObject  ( 4  2  ‘GlobalizeDerivedObject) 

>  Method  Specific  Rules:  ‘GlobalizeDerivedObject 
Method  Ordering:  GDO 

Step  1.5:  (try)  Relormulaie  p.new  as  global 

Candidate  Set: 

□  ReformulateLocal  AsFirst  (42  ReformulateLocalAsSequenceExpression)  (<  ReformLoc2) 

*  RLAF:  R  bound  to  packases.ever.at.aource 

□  ReformulateLocal  AaLaat  ( 4  2  ReformulateLocal  As  Sec  uenceExpresaion)  (>  ReformLoc2) 

*  RLAL:  R  bound  to  packapes.ever.at.source 

>  General  Rules:  ReformulateLocalAsSequenceExpression 

>  Ordering  Rules:  ReformLoc2 
Method  Ordering:  RLAF( 4 2).  RLAL{ 4 2) 

Step  1.6:  Reformulate  p.new  as  lastfoeasf*)) 

Candidate  Set 

□  0 

no  rules  fired 

Step  1 .7 :( user )  Manual  manual- replaced  .new  last(peas)) 

Candidate  Set 
□  manual  step 
no  rules  fired 

Step  1.8:  Maintainlncrementally  previous.package 
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Candidate  5tj 

□  SMFDR:  ScatterMaintenanceForOerivedRelation  ( *  2 
’ScatterMaintenanceForDerivedRelation) 

>  Method  Specific  Rules:  ’ScatterMaintenanceForDerivedRelation 
Method  Ordering  SMFDR(  +  2) 

Step  1.9:  Flatten  previous.package 

Candidate  Set 

□  Flatten  (  +  2  ’Flatten) 

>  Method  Specific  Rules:  ’Flatten 
Method  Ordefino:  Fletten(  +  2) 

Step  1.10:  Map  peas 

Candidate  Set 

□  MDR:  MaintainDerivedRelation  ( *  2  *MDR) 

□  UDR:  UnfoldOerivedRelation  ( +  2  "UnfotdDerivedRelationl)  (-2  MapSubOfRemove2) 

>  Generel  Rules:  MapSubOfRemove2 

>  Method  Specific  Rules:  ’MaintainDerivedRelation.  ’UnfotdDerivedRelationl 
Method  Ordering:  MDR(  +  2) 

Comment:  Normally.the  methods  tor  maintaining  and  unfolding  a  derived 
relation  compete  equally.  However,  the  general  rule  MapSubOIRemove 
recognhies  certain  contexts  In  which  scattering  what  is  currently  a 
global  definition  may  lead  to  difficulties  further  along  in  tha  development, 
l.e.  If  we  are  trying  to  remove  a  relation  then  scattering  references  to  it 
througout  the  program  is  a  non-cooperating  strategy. 

Step  1.11:  Maintainlncrementally  peas 

Candidate  Set 

□  ISMD:  IntroduceSeqMaintenanceDemon  ( ♦  i  DemonaAreGood)  ( *  i  MapSubOfRemovel)  ( ♦  1 
ReadyToGo)  ( ♦  1  ReformUnnecessary) 

□  SMFDR:  ScatterMaintenanceForDerivedRelation  (-2  MapSubOfRemove2)  ( ♦  2  ’SMFDR) 

>  General  Rules:  DemonaAreGood,  MapSubOfRemovel ,  MapSubOfRemove2 

>  Method  Specific  Rules:  ’ScatterMaintenanceForDertvedRetation 

>  Resource  Rules :  ReformUnnecessary ,  ReadyT oGo 
Method  Ordering;  ISMD(  +  4) 
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Step  1.12;  Remove  reference  peas  from  spec 

Candidal*  Sat 

□  BabyWith  Bathwater 

*  BWBWi:  Y  bound  to  re/et/ve-refr/evef  (-2  *BabyWithBathWater3) 

*  BWBW2:  Y  bound  to  derived-object  (-2  *BabyWithBathWater3) 

*  BWBW3:  Y  bound  to  update  (-2  *BabyWithBathWater3) 

*  BWBW4:  Y  bound  to  atomic  (-2  ‘BabyWithBathWater3) 

*  BWBW5:  Y  bound  to  demon  (-1  *BabyWithBathWater2) 

□  MegaMove  (♦  1  Fillln) 

*  MM1 :  Y  bound  to  relative-retrieval  ( 4  2  ‘MegaMovel)  (<  RemoveRef2) 

*  MM2:  Y  bound  to  derived-object  (-2  ‘MegaMove2)  p  RemoveRef2) 

□  PositionalMegaMove  (4 1  Fillln) 

*  PMMi :  Y  bound  to  relative-retrieval  ( 4 1  ‘PositionalMegaMove)  (<  RemoveRef3) 

*  PMM2:  Y  bound  to  derived-object  ( 4 1  ‘PositionalMegaMove)  Q  RemoveRet3) 

□  RemoveByObjectizingContext 

*  RBOCl :  Y  bound  to  relative-retrieval 

*  RB0C2:  Y  bound  to  derived-object 

□  ReplaceRefWithValue  (4 1  Fillln)  (-2  *ReplaceRefWithValue2) 

>  Genera/  Rutty.  Fillln 

>  Method  Specific  Rules:  ‘MegaMovel,  >MegaMove2,  ‘BabyWithBathWater, 

‘PositionalMegaMove ,  *  RepiaceRel  WithValue2 

>  Ordering  Rules:  RemoveRef2.  RemoveRef3 

Method  Ordering:  PMM2(4  2),  PMM1<4  2),  {RBOCl (•).  RBOC2(-)} 

Step  1.13:  Reformulate  derived -object  as  positional-retrieval 

Candidate  Set 

□  RDO:  ReformuiateDerivedObject  {4  2  ‘ReformuiateDerivedObject) 

>  Method  Specific  Rules:  ‘ReformuiateDerivedObject 
Method  Ordering:  R00<4  2) 

Comment:  Note  that  It's  up  to  the  user  to  determine  "close  to"  here,  l.e.  he 
must  determine  H  the  body  of  the  derived  object,  a  reiatinai  retrieval,  can 
be  changed  Into  a  positional  one. 
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Step  1.14:  Reformulate  relative  retrieval  as  equivalence  relation 

Candidate  Set 

□  RRRAF:  ReformulateRelativeRetrievalAsFirst  ( *  1  ReformAsExtrame) 

□  RRRAL:  ReformulateRelativeRetrievalAsLast  ( + 1  ReformAsExtrame)  ( * 1 
ReformUnnecessary)  ( ♦  2  ‘ReformulateRelativeRetrievalAsLast) 

>  General  Rules:  ReformAsExtrame 

>  Method  Specific  Rules:  ‘ReformulateReiativeRetrievalAsLast 

>  Resource  Rules:  ‘ReformUnnecessary 
Method  Ordering:  RRRAL(  +  4),  RRRAF(  +  1) 

Step  1.15:  Equivalence  last(peas@p)  and  p 

Candidate  Set 

□  A1 :  Anchorl 

O  A2:  Anchor2  ( *  2  *Anchor2a) 

>  Method  Specific  Rules:  *Anchor2a 
Method  Ordering:  Anchor2(  +  2),  Anchorl (-) 

Step  1.16:  Reformulate  last(peas@p)  as  p 

Candidate  Set 

□  RAO:  ReformulateAsObject  ( +  1  ReformUnnecessary)  (  + 1  ReadyToGo) 

>  Resource  Rules:  ReformUnnecessary,  ReadyToGo 
Method  Ordering:  RAO(  +  2) 

Step  1.17:  /so/are  last(peas) 

Candidate  Set 

□  FGIR:  FoldGenericIntoRelation  ( *  2  *FGIR) 

>  Method  Specific  Rules:  ‘FoidGenerielntoRelation 
Method  Ordering:  FGIR(  +  3) 

Step  1.18:  Maintainlncrementally  last.package 

Candidate  Set 

□  SMFDR:  ScatterMaintenanceForDerivedRelation  ( ♦  2  ‘SMFDR) 
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>  Method  Specllic  Rufs:  *  Sea  tterMaintenanceForOerived  Relation 
Method  Ordering  SMFDR(  +  2) 

Step  1.19:  Remove  reference  peas  from  spec 

Candidate  Set 

□  BabyWithBathWater 

*  BWBWi:  Y  bound  to  concet  (-2  *BabyWithBathWater3) 

*  BWBW2:  Y  bound  to  list  (-2  ‘BabyWithBathWater3) 

*  BWBW3.  Y  bound  to  update  (-2  ‘BabyWithBathWater3) 

*  BWBW4:  Y  bound  to  atomic  (-2  *BabyWithBathWater3) 

*  BWBW5:  Y  bound  to  demon  (-1  ’Baby  With  Bath  Water2) 

□  MegaMove  ( + 1  Fillln)  (<  RemoveRef4) 

*  MMi :  Y  bound  to  co  n  cat  ( ♦  2  *  MegaMove  t)  (<  RemoveRef  2)  P  RemoveRefl) 

*  MM2:  Y  bound  to  test  ( +  2  *MegaMovel)  P  RemoveRe(2)  p  RemoveRefl) 

□  PositionalMegaMove  (+ 1  Fillln)  {<  RemoveRef4)  (<  RemoveRefl) 

*  PMMi :  Y  bound  to  concet  ( ♦  1  *Poaition«lMegaMove)  (<  RemoveRef3) 

*  PMM2:  Y  bound  to  last  <  + 1  ’PositionalMegaMove)  ( 1  RaformUnneceaaary)  p 
RemoveRef3) 

* 

□  RemoveByObiectizingContext  ( + 1  Fillln) 

*  RBOCl :  Y  bound  to  concat 

*  RBOC2:  Y  bound  to  last  ( ♦  2  ‘RemoveByObjectizingContext)  P  RemoveRef4) 

□  RepiaceRefWithVaiue  (♦ 1  Fillln)  (-2  ’ReplaceRefWith Value) 

>  Ganarti  Rules  :  Fill  in 

>  Method  Specific  Rules:  ‘RemoveByObjectizingContext,  ‘MegaMovel,  ‘BabyWithBathWater, 

‘PositionalMegaMove 

>  Resource  Rules :  ReformUnnecessary 

>  Ordering  Rules:  RemoveRefl,  RemoveRef2,  RemoveRef3,  RemoveRef4 

Method  Ordering:  RBOC2<  ♦  3),  MM2(  ♦  3),  MM1(  ♦  3),  PMM2(  ♦  3).  PMM1(  ♦  2),  RBOC1<  ♦  1) 

Step  1.20:  Reformulate  last(peas@p)  as  object 

Candidate  Set 

O  RAO:  ReformulateAaObject  ( *  1  ReformUnnecessary)  ( ♦  1  ReadyToOo) 
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>  Resource  Rules:  ReformUnneceesary,  ReadyToGo 
Method  Ordering:  RA0(+2) 

Step  1 .21 :  Remove  update  peas  from  spec 

Candidate  Set 

□  BabyWithBathWater 

*  BWBW1 :  Y  bound  to  atomic  (-2  *BabyWithBathWater3) 

*  BWBW2:  Y  bound  to  demon  (-1  *BabyWithBathWater2) 

□  RUA:  RemoveUnused  Action  (+  2  *RemoveUnuaedAction1)iselO 

>  Method  Specific  Rules :  'RemoveUnusedActionl 
Method  Ordering:  RUA(  +  2) 

Step  1.22:  Show  update  unnoticed 

Candidate  Set 

□  SD:  ShowDysteieological  ( + 1  'ReadyToGo)  { <►  2  'ShowDysteleotogical) 

>  Method  Specific  Rules:  'ShowDysteieological 

>  Resource  Rules:  ReadyToGo 


Method  Ordering:  SD(  +  3) 
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D.2.  Remove  PREVIOUS_PACKAGE 

Step  2.1:  Remove  previous  package 

Candidal*  Sat 

□  RR:  RemoveRelation  ( ♦  2  BurnedOutHulk)  ( *  2  *RemoveRelation2) 

>  General  Rules:  BurnedOutHulk 

>  Method  Specific  Rules:  *RerooveRelation2 
Method  Ordering:  RR(  +  «) 

Step  2.2:  Remove  reference  previous_package  from  spec 

Candidate  Set 

□  BabyWithBathWater 

’  BWBWi :  Y  bound  to  conditional (0  *BabyWithBathWaterl) 

*  BWBW2:  Y  bound  to  demon  (-1  ‘Baby  With  Bath  Water2) 

□  MegaMove  ( *  2  Fillln)  (<  RemoveRet6) 

*  MM:  Y  bound  to  attribute- reference  ( ♦  2  'MegaMowei) 

□  PositionalMegaMove  (+ 1  Fillln)  (<  RemoveRet6) 

*  PMM:  Y  bound  to  attribute- reference  ( ♦  i  'PositionalMegaMove) 

□  RemoveByObjectizingContext  { *  1  Fillln) 

*  RBOC:  Y  bound  to  attribute-reference 

□  RRWV:  RepiaceRefWithValue  (+1  Fillln)  (♦  2  *ReplaceRefWithValuel){>  RemoveRefB) 

>  General  Rules:  Fillln 

>  Method  Specific  Rules.  'MegaMovei,  ‘BabyWithBathWater.  'RepiaceRetWithValuet 

>  Ordering  Rules:  RemoveRefB 

Method  Orderina:  RRWV(  +  3),  MM(  ♦  3).  PMM{  ♦  2).  RBOC{  * 1) 

Step  2.3:  Snow  value  known  of  previousjackage 

Candidate  Sat 

□  ShowUpdateGiveaVaiue 

*  SUGV  u  bound  to  update  in  notice.new_package.at .source  ( +  2 
'ShowUpdateGiveaVaiue) 

>  Method  Specific  Rules.  ‘ShowUpdateGiveaVaiue 
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Method  Ordering:  SUGV(  +  2) 

Step  2.4:  Show  last.package  still  holds  at  conditional 

Candidate  Set 

□  SNVSV:  ShowNewValueStillValid  ( +  2  *ShowNewValueStillValid)iaelO 
Method  Or  da  ring.  SNVSV(f2) 

Step  2.5:  Show  last.package  doesn't  change 

Candidate  Sat 

□  Movelntervening  Update 

*  MIU:  L  bound  to  update  in  notice.new.pacnage.at.aouree  ( *  1  ReadyToGo)  ( +  2 
*MoveinterveningUpdate)isal() 

>  Method  Specific  Rules:  *MovelnterveningUpdate 

>  Resource  Rules:  ReadyToGo 
Method  Ordering  MIU(  +  3) 

Step  2.6:  ComuteSequentially  conditional  before  update  of  last.package 

Candidate  Sat 

□  MOOA:  MovaOutOf  Atomic  (  +  2  ’MoveOutOf  Atomic) 

>  Method  Specific  Rules:  ’MoveOutOf  Atomic 
Mathod  Ordering:  MOOA(  +  2) 

Step  2.7:  Unfold  atomic 

Candidate  Set 

□  UA:  Unfold  Atomic  (  +  5  ’Unfold  Atomic) 

>  Method  Specific  Rules:  ’UnfoldAtomic 
Method  Ordering:  U A(*5) 

Comment:  A  weight  of  *  5  Implies  thet  there  Is  no  other  method,  now  or 
foreseen,  which  can  achieve  the  goal.  In  some  sense,  the  goal  is  an 
abstract  pointer  to  the  method. 

Step  2.8:(reposfecf)  ComuteSequentially  conditinal  before  update  of  lastj>ackage 


Candidate  Set 
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□  CTMS  Consolidate! oMakeSequential  ( *2  ’ConsoiidateToMakeSequential) 

>  Method  Specific  Rul*s:  'ConsoiidateToMakeSequential 
Mathod  Ordering:  CTMS(-r2) 

Step  2.9:  Consolidate  notice  new  package  at  source 
and  release jjackage.into.network 

Candidate  Set 

D  MO:  Merge  Demons  ( +  S  •  Merge  Demons) 

>  Mathod  Spacilic  Rules:  'Merge Demons 
Method  Ordering:  MD(  +  5) 

>  Action  Ordaring  Rulas:  TriggersAlmostEquiv 

Step  2.10:  Equivalence  declaration  lists 

Candidate  Set 

□  A1 :  Anchorl 

□  A2:  Anchor2 

□  ECS:  EquivalenceCompoundStructures2  (*  2  *EquivalenceCompoundStructut«s2) 

>  Mathod  Spacilic  Rulas:  *EquivalenceCompoundStructures2 
Method  Ordering  ECS(  +  2) 

Step  2.11:  Equivalence  p  and  p.new 
Candidate  Set 

□  Al:  Anchorl  (  +  2  ‘Anchorl a)  (<  EquivVarsl) 

□  A2:  Anchor2  ( +  2  *Anchor2a)  (>  EquivVarsl) 

>  Mathod  Spacilic  Rulas:  ‘Anchorl  a,  *Anchor2a 

>  Ordaring  Rulas :  EquivVarsl 
Method  Ordering:  A2(  +  2) 

Comment:  Until  have  thaory  o  1  mnemonics,  user  railed  upon  to  select 
names. 

Step  2.1 2:  Reformulate  p  as  p.new 

Candidate  Set 
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□  RV:  RenameVar  { +  2  ‘RenameVar) 

>  Method  Specific  Rules-.  ‘RanamaVar 
Method  Ordarino:  RV(  +  2) 
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Step  2.1 3:(reposfecf)  ComuieSequentially  conditional  before  update  of  last.package 

Candidate  Sat 

□  SU:  SwapUp  ( +  2  ’SwapUp) 

►  Method  Specific  Rules:  ‘SwapUp 
Method  Ordering:  SU(*2) 


II 


S; 


i 


Step  2.14:  Swap  update  of  last.package  with  conditional 

Candidate  Set 

□  SS:  SwapStatements  ( *  $  ‘SwapStatements) 

>  Method  Specific  Rules.  ‘SwapStatements 
Method  Ordering:  SS(  +  5) 
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D.3.  Remove  LAST-PACKAGE 
Step  3.1: (user)  Remove  last  package 

Candidate  Set 

□  RR:  RemoveReiation  ( +  2  Burned  OutHulk)  ( ♦  2  *RemoveRelation3) 

>  General  Rules  :  BurnedOutHulk 

>  Method  Specific  Rules:  *RemoveRelation3 
Method  Ordering:  RR(  +  4) 

Step  3.2:  Remove  reference  last.package  from  spec 

Candidate  Set 

□  BabyWithBathWater 

*  BWBW1 :  Y  bound  to  conditional (0  ‘BabyWithBathWaterl) 

*  BWBW2:  Y  bound  to  demon  (-1  *BabyWithBathWater2) 

□  MegaMove  ( ♦  1  Fillln) 

*  MM:  Y  bound  to  etiributa-ratarance  (♦  2  ‘MegaMovet)  (>  RemoveRef  1) 

□  PositionalMegaMove  { + 1  Fillln)  (<  RemoveRef  1) 

*  PMM:  Y  bound  to  ettributo-rafmranco  { ♦  1  ‘PoaitionalMegaMove) 

□  RemoveByObjectiringContext 

*  RBOC:  Y  bound  to  attribute-reference 

□  RRWV:  ReplaceRefWithValue 

>  General  Rules.  Fillln 

>  Method  Specific  Rules :  *MegaMovel ,  ’BabyWithBathWater,  ‘PoaitionalMegaMove 

>  Ordering  Rules:  RemoveRef  1 

Method  Ordering  MM( 4  3),  PMM{  4  2),  {RBOC(-),  RRWV(-)) 

Step  3.3:  isolate  last_package:destination 

Candidate  Set 

□  FGIR:  FoWGenericIntoRelation  ( 4  5  ‘FoldGenericIntoRelation) 

>  Method  Specific  Rules:  ‘FoldGenericIntoRelation 
Method  Ordering:  PGIR(4S) 
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Step  3.4:  Maintainlncrementally  last.package.destination 

Candidate  Set 

□  SMFDR:  ScatterMaintenanceForOerivedRelation  ( ♦  2  ScatterWaintenanceForDerivedRelation) 

>  Method  Specific  Rules'.  ’ScatterMaintenanceForDerivedRelation 
Method  Ordering:  SMFDR(  +  2) 

Step  3.5:  Remove  update  of  last.package 

Candidate  Set 

□  BabyWithBath  Water 

*  BWBW1:  Y  bound  to  atomic  (-2  'BabyWithBath Water3) 

*  BWBW2:  Y  bound  to  demon  (-1  ’BabyWithBathWater2) 

□  RUA:  Removellnused Action  (  +  2  ’RemoveUnusedActionl) 

►  Method  Specilic  Rules:  *BabyWithBathWater2,  ’BabyWithBath Waters,  ’RemoveUnusedAction 
Method  Ordering:  RUA(  +  2) 


D.4.  Map  DlD_NOT_SET_SWITCH„WHEN_HAD_CHANCE 

Step  4.1  :(user)  Mao  did.not.set.switch.when.had.chance 
Caeflidaii  set 

□  MCAD:  MapConstraintAs Demon  ( 4 1  DemonsAreGood)  ( 4  2  *MCAD) 

□  UC:  UnfoldConstraint 

>  General  Rules  :  DemonsAreGood 

>  Mat  hod  Specific  Rules:  *MCAD 
Method  Ordering:  MCA 0(4 3) 

Comment:  Of  course  the  difficult  decision  here  is  determining  whether  a 
pridictive  or  backtracking  solution  is  possible.  The  system  points  out  the 
need  lor  making  the  decision,  the  user  provides  the  answer. 

Step  4.2:  Show  body  implies  Q 

Candidate  Set 

□  ConjunctlmpliesConjunctArm  ( 4 1  UseConjunctArm) 

*  ClCAi :  A  bound  to  first  conjunct  arm  (-2  *CICA2) 

*  CICA2:  A  bound  to  second  conjunct  arm  (-2  *CICA2) 

*  CICA3:  A  bound  to  third  conjunct  arm  { 4  2  ’CICA1) 

>  General  Rules  :  UseConjunctArm 

>  Method  Specific  Rules:  'ConjunctlmpliesConjunctArml ,  *ConjunctlmpliesConjunctArm2 
Method  Ordering:  CICA3(4  3) 

Comment:  The  system  points  out  the  selection  conditions  which  must  be 
attended  to ;  the  user  determines  which  of  the  candidates  satisfies  the 
conditions. 

Step  4.3:  Map  set.switch.when.have.chance  (sswhc) 

Candidate  Spt 

□  CO:  CasityDemon  ( 4  2  CaslfyComptexConatruct)  (<  MapDemonl) 

□  MapByConaolidation 

*  M8C1 :  D2  boudn  to  aet.switch  ( 4  2  *MBC2)  0>  MapDemonl ) 

*  MBC2:  D2  bound  to  release j>acKage.into.networK  ( 4 1  *MBCi) 

*  MBC3  D2  bound  to  misrouted .pacKage.reaehed.bin 
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*  MBC4  D2  bound  to  create.package  ( *  2  *MBC2)  (-2  *MBC4) 

*  MBC5:  D2  bound  to  movej>ackage  ( ♦  2  *MBC2)  (-2  *MBC4) 

*  MBC6  02  bound  to  package.entering.sensor  ( *  1  *MBC1) 

*  MBC7;  D2  bound  to  packs  ge.ieavi  ng.se  nsor  ( 4 1  *MBCi) 

□  UD:  UnfokJDemon  (42  *UD)  (<  MspDemonl) 

>  Central  Rules.  CasifyComplexConstruct 

>  Method  Specific  Rules:  ‘MapByConsoiidationl,  *MapByConsofidation2,  *MapByConsolidation4, 

‘Unfold  Demon 

>  Ordering  Rules:  MapDemonl 

Method  Ordering:  MBC1  ( 4  2),  {CD(  4 2),  UD( 4  2)>.  <MBC2( 4 1),  MBC6( 4 1).  MBC7(  4 1)} 

Step  4.4:  Consolidate  sswhc  and  set.switch 

Candidate  Set 

□  MO:  MergeOemons  ( 4  5  ‘MergeDemons) 

>  Method  Specific  Rules:  ‘MergeOemons 
Method  Ordering:  MD(4  5) 

Step  4.5:  Equivalence  two  triggers 

Candidate  Set 

□  A1 :  Anchorl 

□  A2:  Anchor2  ( 4  5  *Anchor2b) 

>  Method  Specific  Rules:  *Anchor2b 
Method  Ordering:  A2(4  5) 

Step  4.6:  Reformulate  random  as  specific 

Candidate  Set 

□  SR:  SpecializeRandom  ( 4  5  ‘SpecializeRandom) 

>  Method  Specific  Rules:  ‘SpecializeRandom 
Method  Ordering:  SR(4  5) 

Step  4.7:(user)  Mao  require  ~P  from  ThisEvent  until  EverMore 
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Candidate  Set 

□  CPC:  CasifyPosConstraint  ( ♦  2  CasHyComplexConstruct)  (>  MapConstraintl) 

□  MCTA:  MoveConstraintToAction 
O  NXUX:  NotXUntilX 

□  TIC:  TriflgerlmpliesConstraint 

□  UC:  UrrfoldConstraint  ( +  2  TnfoldConatraint)  (<  MapConstraintl) 

>  General  Rules:  CasrfyComplexConatruct 

>  Method  Specific  Rules:  *UnfoldConstraint 

>  Ordering  Rules:  MapConstraintl 

Mathod  Ordarino:  CPC(  ♦  2),  UC(  ♦  2),  (MCTA(-),  NXUX(-),  TIC<)} 

Step  4.8:  Casify  require  -P  from  ThisEvent  until  EverMore 

Candidate  Sat 

□  BS:  BinarySplit  ( +  1  ReadyToGo)  (-2  *BinarySplit2) 

□  PI:  Pastlnduction 

□  CFUEC:  CasifyFromUntilEverConatraint  <-*  1  RatormUnnacaasary)  ( 4 1 
RequireReformUnnacassary) 

□  CAE:  CasifyAroundEvant 

>  Method  Specific  Rules:  *BinarySp!it2 

>  Resource  Rules:  RatormUnnacaasary.  RaquireReformUnnacesaary,  ReadyToGo 
Mathod  Ordering:  CFUEC( *  2).  {Pl(-),  CAE(-)} 

Step  4.9:  Map  require  ~P  at  ThisEvent 

Candidate  Sat 

□  CPC:  CasityPosConstraint  ( ♦  2  CaaifyComplexStructura)  0  MapConstraintl)  (< 
MapConstraint2) 

□  MCAC:  MoveConstraintToAction 

□  NXUX:  NotXUntilX 

□  TIC:  TriggerlmpliesConstraint  ( 4  t  RatormUnnacaasary)  (  +  i  RaquiraRatormUnnacassary) 
(4 1  ReadyToGo)  (>  MapConstraint2) 

□  UC:  UnfoMConstraint  ( 4  2  *UnfoldConstraint)  (<  MapConstraintl)  (<  MapConstraint2) 

>  Qenerei  Rules :  CasHyComplexConstruct 
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>  Method  Specific  Rubs-  'UnfoWConstraint 

>  Resource  Rules:  ReadyToGo.  ReformUnnecesaary,  RequireReformUnnecessary 

>  Ordering  Rules:  MapConstraintl ,  MapConstraint2 
Method  Ordering:  TIC(  +  3),CPC<*2),UC<  +  2) 

Step  4.10:  Map  require  ~P  after  ThisEvent 

Candidate  Sat 

□  CPC:  CasifyPosConstraint  ( +  2  CasifyComplexConstruct)  p  MapConstraintl ) 

□  MCTA:  MoveConstraintToAction 

□  NXUX:  NotXUntilX 

□  TIC:  TriggerlmpliesConstraint 

□  UC:  UnfoldConstraint  (  +  2  *UC)  (<  MapConstraintl) 

>  General  Rules.  CasifyComplexConstruct 

>  Method  Specilic  Rules:  'UnfoldConstraint 

>  Ordering  Rules:  MapConstraintl 

Method  Ordering:  Caaif y PosConst reint(  +  2),  UnfoldConstraint(  +  2) 

Step  4.11:  easily  require  ~P  after  ThisEvent 

Candidate  Set 

□  BinarySplit  ( *  1  ReadyToGo)  (-2  *BinarySplit2) 

□  Pastlnduction 

□  CasHyFromUntilEverConstraint 

» 

□  CasifyAroundEvent  ( ♦  1  ReformUnnecessary)  ( + 1  RequireReformUnnecessary) 

>  Method  SpecHic  Rules:  *BinarySplit2 

>  Resource  Rules:  ReadyToGo,  ReformUnnecessary,  RequirieReformUnnecessary 

Method  Ordering:  Casify A roundEvs  nt(  *  2),  {Pastlnduction(-),  CasifyFromUntilEverConstraint(-)} 


Step  4.1 2:  Map  require  ~P  after  ThisEvent  until  E 

Candidate  Set 

□  CasifyPosConstraint  ( +  2  CasifyCompiexStrueture)  P  MapConstraintl)  (<  Map  Constraint?) 


□  MoveConstraintToAction 
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□  NotXUntilX  (  + 1  ReformUnneceaaary)  ( ♦  1  RequireRef  ormUnnecesaary)  (>  MapConetraint2) 

□  TriggerlmpliesConatraint 

□  Unf  oldConstraint  (  +  2  *UC)  (<  MapConstraintl )  (<  MapConstraint2) 

>  General  Rules:  CasifyComplexConstruct 

>  Method  Specific  Rules:  ReadyToGo,  ReformUnneceaaary,  RequireReformUnnecessary 

>  Ordering  Rules:  MapConstraintl,  MapConstraint2 

Mai  hod  Ordering:  NotX  UntilX(  +  2),  CasifyPosConstraintf  4  2),  UnfoldConstraint(  +  2) 

Step  4.13:  Map  ~P  during  E 

Candidate  Sat 

□  CasifyPosConstraint  ( +  2  CasJfyComplexStructure)  (>  MapConstraintl) 

□  MoveConStraintT  o  Action 

□  NotXUntilX 

□  TriggerlmpliesConstraint 

□  Unf  oldConstraint  ( 4  2  ‘Unof  Id  Constraint)  (<  MapConstraintl) 

>  General  Rules:  CaaityCompiexConstTuct 

>  Method  Specific  Rules:  *Unf oldConstraint 

>  Ordering  Rules:  MapConstraintl 

Mathod  Ordarina:  Casif y PosConat raint( ♦  2),  UnfoldConstrainK  +  2),  {MoveConstraintToAction(-), 
NotXUntiiX(-).  TriggerlmpliesConstraint(-)} 

Step  4.14:  Casify  require  ~P  during  E 

Candidata  Sat 

□  BinarySplit  ( + 1  ReadyToGo)  (-2  *BinarySplit2) 

□  Pastlnduction  (+ 1  ReformUnneceaaary)  (♦  1  RequireReformUnnecessary) 

□  CasifyFromUntilEverConstraint 

□  CasifyAroundEvent 

>  Method  Specific  Rules:  *BinarySplit2 

>  Resource  Rules:  ReadyToGo,  ReformUnnecessary,  RequireReformUnnecessary 

Mathod  Ordering:  Past  Indue  tlon(  4  2),  {CaalfyFromUntilEverConatraint(-),  CaaifyAroundEvent(-)} 
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Step  4.15:  Map  require  ~P  at  last  update  switch.setting 

Candidate  Sat 

□  CasityPoaConstraint  ( +  2  CasifyComplexStructure)  (>  MapConstraintl)  (<  MapConstraint3) 

□  MoveConatraintToAction  (  + 1  ReformUnnecessary)  (+ 1  RequireReformUnnecessary)  (> 
MapConstraint3) 

□  NotXUntilX 

□  TriggerlmpliesConstraint 

□  UnfoldConstraint  (  +  2  ‘UrrfoldConstraint)  (<  MapConatraintl) 

>  General  Rules:  CaaityComplexConatruct 

>  Method  Specific  Rules:  ‘UrrfoldConstraint 

>  Resource  Rules:  RetormUnnecesaary,  RequireReformUnnecessary 

>  Ordering  Rules:  MapConatraintl,  MapConstraint3 

Method  Ordering:  MoveConat  raintTo;.ction( ♦  2),  CaaifyPosConstraint(  +  2),  UnfoldConstraint( ♦  2), 
(NotXUntilX(-),  TriggerlmplieaConatraint(-)} 

Step  4.16:  Map  require  ~ (start  of  ~P)  between  last  update,  E 

Cendidete  Set 

□  CasifyPoaConatraint  ( ♦  2  CasityComplexStructure)  (>  MapConstraintl)  (<  MapConstraint2) 

□  MoveConatraintToAction 

□  NotXUntilX 

□  ShowNoChange  ( ♦  2  ’ShowNoChange)  (>  MapConstraint2) 

□  TriggerlmpliesConstraint 

□  UnfoldConatraint  (4  2  "Unfold Constraint)  (<  MapConstraintl) 

>  General  Rules:  CaaityComplexConatruct 

>  Method  Specific  Rules:  ‘ShowNoChange 

>  Ordering  Rules:  MapConstraintl ,  MapConstraint2 

Method  Ordering:  ShowNoChange( * 2),  Casif yPosConstraint( * 2),  Urtf oldConstraint( ♦ 2) 

Step  4.1 7:  Show  -(start  -P)  between  last  update,  E 


Candidate  Set 
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Step  4.1 8:(user)  Map  update  of  switch.setting  where  P 

Candidate  Sat 

□  CNV:  ComputeNew  Value  (+2  *ComputeNewValue) 

>  Method  Specific  Rules:  *ComputeNewValue 
Method  Ordering:  CNV(  +  2) 

Step  4.19:  Unfold  switch  set  wrong  for  package  at  set  switch 

Candidate  Set 

□  SCOOR:  ScatterComputationOtDerivedRelation  ( ♦  5  ‘ScatterComputationOfDerivedRelation) 

>  Method  Specific  Rules:  *ScatterComputationOfDerivedRelation 
Method  Ordering:  SCODR(fS) 
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D.5.  Map  PACK  AGES_DUE_AT_S  WITCH 

Step  5.1  l(user)  Mao  packages  due  at  switch  (pdas) 

Candidate  Set 

□  MDR:  MaintainDerivedRelation  (  +  2  •MaintainDerivedReiation)  (>  MapDR2a) 

D  UOR:  UnfokJDerivedRelation  (+2  *UnfoldDerivedRelation1)  (<  MapDR2a) 

>  Method  Specific  Rules:  ‘MaintainDerivedRelation,  ‘UnfoidDerivedRelationi 

>  Ordering  Rules:  MapDR2a 

Method  Ordering:  MDR(  4  2),  UDR(  +  2) 

Comment:  Currently,  the  system  has  no  mechanism  tor  computing  the 
letthandside  o I  MapDRZ,  i.e.  It  is  up  to  the  user  to  determine  the  cost  of 
computing  the  relation. 


Step  5.2:  Maintainlncremenlally  pdas 

Candidate  Set 

□  IntroduceSeqMaintenanceDemon  ( *  1  DemonaAreGood)  ( + 1 
“IntroduceSeqMaintenance Demon)  (4 1  ReformUn necessary)  (<  MaintDRl) 

□  ScatterMaintenanceForDerivedRalation  { 4  2  *SMFDR)  (>  MaintDRl) 

>  General  Rules:  DemonsAreGood 

>  Method  Specific  Rules.  ‘IntroduceSeqMaintenanceDmeon,  ‘ScatterMaintenacneForDerivedRelation 

>  Resource  Rules:  ReformUn  necessary 

>  Ordering  Rules:  MaintDRl 

Method  Ordering:  SMFDR(*2),  ISMD(  +  3) 

Step  5.3:  Flatten  pdas 

Candidate  Set 

□  Flatten  ( ♦  2  ‘Flatten) 

>  Method  Specific  Rules:  ‘Flatten 
Method  Ordering:  Flatten(  +  2) 

Step  5.4:  Map  location.on.route.to.bin 

Candidate  Set 


□  StoreExplicitly  ( 4  2  ‘StoreExplicitly)  (>  MapDRIa) 
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□  Unfold  Derived  Relation  (-2  *UnfoklDerivedRelation2)  (<  MapDRla) 

>  Method  Specific  Rules:  "StoreExpticitly,  "Uni  old  Derived  Ret  «tion2 

>  Ordering  Ruin:  MapDRla 
Method  Ordering:  StoreExplicitly(4  2) 

Step  5.5:  Map  misrouted 

Candidate  Set 

□  MDR:  MaintainDerivedReiation  ( ♦  2  'MaintainDerivedReiation)  (<  Map  DR  2b) 

□  UDR:  Unfold  Derived  Relation  ( *  2  *Unf  oldDerivedRelationl)  0  MapDR2b) 

>  Method  Specific  Rules.  'MaintainDerivedReiation,  'UnfotdDerivedRelationl 

>  Ordering  Rules :  MapDR2b 
Method  Ordering:  MOR( ♦  2),  UDR(  4  2) 


Step  5.6:  Unfold  misrouted  at  pdas 

Candidate  Set 

□  SCODR  ScatterComputationOt  Derived  Relation  ( ♦  5  '  ScatterComputationOf  Derived  Relation) 

>  Method  Specific  Rules  .  'ScatterComputationOf  Derived  Relation 
Method  Ordering.  SCODR(  +  5) 

Step  5.7:  Flatten  pdas 

Candidate  Set 

□  Flatten  (4  2 -Flatten) 

>  Method  Specific  Rules:  'Flatten 
Method  Orderlna:  Flatten!  4  2) 


Step  5.8:  Map  switch_set_wrong.for_package 

Candidate  Set 

□  MDR:  MaintainDerivedReiation  ( 4  2  'MaintainDerivedReiation)  (<  Map  DR  2b) 

□  UDR:  Unfold  Derived  Relation  ( 4  2  *  UnfoldDerived  Relation  1 )  (>  Map  DR  2b) 

>  Method  Specific  Rules:  'MaintainDerivedReiation,  'Unfold Derived Relationl 

>  Ordering  Rules:  MapDR2b 
Method  Orderlna:  UOR(  4  2),  MOR(  4  2) 
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Step  5.9:  Unfold switch_set_wrong_for_package 

CandidiU  Set 

□  SCODR:  ScatterComputationOfDerivedRelation  ( ♦  5  'ScattefCompotationOfOerivedflefation) 

>  Method  Specific  Ruias:  •ScatterComputationOtDerivedRelation 
Mathod  Ordering:  SC0DR(  +  5) 

Step  5.10:  Purify  loop  in  create  .package 
Candidata  Sat 

□  PurHyDemon  ( ♦  2  ‘PurHyDemon) 

>  Mathod  SpacHic  Buies:  ‘PurityDemon 
Mathod  Ordering:  PurityDemon! +  2) 

Step  5.11:  Remove  loop  from  create_package 

Candidata  Sat 

□  BabyWithBathWater 

*  BWBWi :  Y  bound  to  atomic  (-2  *BabyWithBathWater3) 

*  BWBW2  Y  bound  to  demon  (-2  *BabyWithBathWatar3) 

□  RFD:  RamoveFromDamon  (  +  2  *  RamoveFromDamon)  (<  RamActl) 

□  RUA:  RamovaUnuaad  Action  (+2  *RemoveUnuaedAction2)  (>  RamActl) 

>  Mathod  SpacHic  Buies:  ‘BabyWlthBathWatar3,  •RamowaFromDamon.  *RemoveUnuaadAction2 

>  Ordering  Buies:  RamActl 

Mathod  Ordering:  RUA{*2),  RFD{  +  2) 

Comment:  The  system  does  not  have  the  necessary  knowledge  to 
determine  what  code  can  be  simplified  away  end  whet  must  remain. 

Because  of  the  big  gain  in  problem  solving  costs,  the  system  always 
suggests  blowing  away  unioided  code  before  moving  It  about.  Hera,  the 
introduced  loop  Is  necessary  and  hence  must  be  removed  from  the 
demon. 

Step  5.1 2:  Globalize  loop  in  create  .package 

Candidate  Sat 

□  GlobalizeAction  ( *  2  ‘GtobalizeAction) 

>  Method  Specific  Buies:  ‘GlobalizeAction 
Mathod  Ordering:  GlobalizeAction!  +  2) 
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Step  5.13:  Unfold  atomic 

Candidal*  fill 

□  UnloldAtomic  ( +  5  ’Unfold Atomic) 

>  Method  Specific  Rules:  ’UnfoldAtomic 
Mathod  Ofdafino:  UnfoldAtomic(  +  5) 

Step  5.14:  Purify  conditional  in  move.package 

Candidata  Sal 

□  Purif /Demon  ( +  2  ’PurifyDamon) 

>  Method  Specific  Rules:  ’PurifyDemon 
Mathod  Ordarina:  PurifyD*mon{  + 2) 

Step  5.1 5:  Remove  conditional  in  move.package 

Candidata  Sat 

□  BabyWithBathWater 

•  Y  bound  to  atomic  (-2  *  BibyWUhBathW »ter3) 

*  Y  bound  to  demon  (-2  *BabyWithBathWatar3) 

□  RamovaF romDamon  ( *  2  ’RemovaFromDemon)  (<  R*mAct2) 

D  RemoveUnuaed  Action  ( +  2  *R*mov*Unua*dAction2)  (>  Ram  Act  1) 

>  Method  Specific  Rules:  *BabyWithBathWatar3,  ’RemovaUnuaedActiortf,  ’RemoveFromDamon 

>  Ordering  Rules:  RamActl 
Mathod  Ofdafing:  RUA(  2).  RFD( ♦  2) 

Commant:  See  comments  etS.11 

Step  5.16:  Globalize  conditional  in  move.package 

Candidata  Sat 

□  GlobalizaAction  ( ♦  2  ’GlobalizaAction) 

>  Method  Specific  Rules:  ’GlobalizaAction 
Method  Ordarina:  Globaliz*Action(  +  2) 


Step  5.17:  Unfold  atomic 


0.5  Map  PACK  AG  ES_DUE.AT_SWIT  CH 


Candidate  Sit 

□  UnfoldAtomic  ( +  S  ’Unfokf  Atomic) 

►  Mathod  Spacilic  Rulas :  ’UnfoidAtomic 
Method  Ordering  UnfoldAtomic(  +  5) 

Step  5.18:  Qashi  package.leavinfl.sensor 

Candidate  Set 

□  CasifySuperTrigger  ( +  2  ’CasifySuperT rigger) 

>  Mathod  Spacitic  Rulas:  ’CasifySuperTrigger 
Method  Ordering:  CasifySuperTrigger(  +  2) 

Step  5.19:  Casifv  package.entering.sensor 

Candidate  Set 

□  CasifySuperTrigger  ( ♦  2  ’CasifySuperTrigger) 


>  Mathod  Spacitic  Rulas :  ’Casif ySuperT rigger 
Method  Ordering:  CasifySuperTrigger{  +  2) 
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D.6.  Map  Demons 

Step  6.1  '.(user)  Map  set.switch 

Candidate  Sat 

□  CD:  CaaifyDemon  ( +  2  CasifyComplexConstruct)  ( ♦  2  ’CaaifyDemon) 

□  MapByConsolidation 

*  MBC1 : 02  bound  to  releaae.paekage.lnto.network  ( ♦  1  *MBC1) 

*  MBC:2  D2  bound  to  package.entering.awitch  ( 4 1  *MBC1) 

*  MBC3:  D2  bound  to  pacKa9e.entering.bin  ( 4 1  *MBC1) 

*  MB 0<:  D2  bound  to  package.leaving.switeh  (♦  1  *MBC1) 

*  MBC5  02  bound  to  package.leaving.bin  ( 4 1  *MBCl) 

*  MBC6  02  bound  to  init.memo  (4 1  *MBC1) 

*  MBC7:  D2  bound  to  misrouted  .package.reached.bin 

*  MBC6  D2  bound  to  create  .package  (-2  *MBC4)  ( 4 1  *MBC2) 

*  MBC9:  02  bound  to  move.package  (-2  *MBC4)  {4 1  ’MBC2) 

DUD:  UnfoldDemon  (4 1  *Unfo»d Demon) 

>  General  Rules.  CaaifyComplexConatruct 

>  Method  Specific  Rules’  ’CaaWyOemon,  ’MBCl,  ’MBC2,  ’MBC4,  "Unfold Demon 

Method  Ordering:  CD<4  4),  {MBC1(4 1),  MBC2(  4 1),  MBC3(  4  1),  MBC4<  4 1),  MBC5(  4  1).  MBC6(  4 1), 
UD(4l)} 

Step  6.2:  easily  set.switch 

Candidate  Sat 

□  CCT:  CaaifyConjunctiveT rigger  ( 4  2  "CaaifyConjunetiveT rigger) 

>  Method  Specific  Rules.  ’CaaityConjunctiveTrigger 
Method  Ordering:  CCT(4  2) 

Step  6.3:  Map  set.switch.when.bubble.package  (sswbp) 

Candidate  Set 

□  CD:  Caaify  Demon 

□  MapByConaoiidation 
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*  MBCl :  02  bound  to  release.package.into.network  ( + 1  *MBC1) 

*  MBC.2  02  bound  to  package.entering^ewitch  ( + 1  *MBC1) 

’  MBC3:  D2  bound  to  package.entering.bin  ( ♦ 1  *MBC1) 

*  MB 04:  02  bound  to  package.(eaving_switch  (+ 1  *MBC1) 

*  MBC5: 02  bound  to  package.leaving.bin  (+1  *MBC1) 

*  MBC6  D2  bound  to  init.memo  (♦  1  *MBC1) 

*  MBC7: 02  bound  to  misrouted.paekage.reached.bin 

*  MBC8  02  bound  to  set.awitch.on.exit  ( ♦  1  *MBC1)  (-2  *MBC5) 

*  MBC9  02  bound  to  create .package  (-2  *MBC4)  (+ 1  *MBC2) 

*  MBCiO:  02  bound  to  move.package  (-2  *MBC4)  (.+ 1  *MBC2) 

□  UD:  UnfoldDemon  ( + 1  ‘UnfoldDemon) 

>  Method  Specific  Rules:  "MBCl,  *MBC2,  *MBC4.  *MBC5,  ‘UnfoldDemon 

Method  Ofderino:  {MBC1(  ♦  1),  MBC2(  ♦  1),  MBC3<  *  1),  MBC4{  + 1).  MBC5(  + 1),  MBC6(  t- 1),  UD(  +  1)} 

Comment:  User  determines  that  consolidation  doesn't  look  promising. 

Unfolding  a  demon  is  a  strategy  that  in  general  always  works.  It  is  often 
not  a  great  choice  because  of  the  necessary  work  of  opotimning  the 
unfolded  code.  Here  it  is  about  the  only  choice. 

Step  6.4:  Unloid  sswbp  at  release_package_into.network 
Candidate  Set 

□  ScatterComputationOfDemon  ( +  5  ‘ScatterComputationOfDemon) 

>  Method  Specific  Rules:  ‘ScatterComputationOfDemon 
Method  Ordering:  Scatte rCompu tationOf Demon(  +  5} 

Step  6.5:  Factor  update  of  packages.due.at.switch 
Candidate  Set 

□  FactorDBMaintenancelntoAction  ( + 1  ReadyToGo)  (  +  2  ‘FactorDBMaintenancelntoAction) 

>  Method  Specific  Rules:  ‘FactorDBMaintenancelntoAction 

>  Resource  Rules:  ReadyToGo 

Method  Ordering;  FactorDBMaintenancelnto Action) ♦ 3) 


Step  6.6:  Map  set.switch.on.exit 
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*. 


Candidate  Sat 

□  CD:  Casify  Demon 

□  MapByConaolidatlon 

*  MBCi:  D2  bound  to  release .package.into.network  ( ♦  i  *MBCi) 

*  MBC:2  D2  bound  to  package.entering.switch  ( ♦  1  *MBCl) 

*  MBC3:  D2  bound  to  package.entering.bin  ( ♦  1  *MBC1) 

*  MBC4:  D2  bound  to  packs ge.leaving.switch  (•*■  1  *MBC1) 

’  MBC5:  D2  bound  to  package.leaving.bin  (  +  1  *MBC1) 

’  MBC6  D2  bound  to  init.memo  ( + 1  *MBC1) 

*  MBC7:  D2  bound  to  misrouted.paekage.reached.bin 

*  MBC8:  D2  bound  to  createjiackage  (-2  *MBC4)  ( + 1 -MBC2) 

*  MBC9:  D2  bound  to  move.package  (-2  *MBC4)  ( + 1  *MBC2) 

□  UD:  UnfoldDemon  (+ 1  ‘UnfoWDemon) 

>  Method  Specific  Rules :  *MBC1 ,  *MBC2,  *MBC4,  ‘UnfoldDemon 

Method  Ordering  {MBCi ( «•  1).  MBC2(  ♦  1),  MBC3<  *  1).  MBC4( ♦  1),  MBC6(  «•  1),  MBC6(  + 1).  UD(  + 1)} 

Comment:  Ageln  up  to  the  user  to  find  e  promising  consolidetion  demon. 

In  this  case,  a  level  of  Indirection  is  Involved  vis  a  vis  the  derived  reletion 
SWITCH.IS.EMPTY. 

Step  6.7:  Consolidate  set_switch.on.exit  and  package.leaving.switch 

Candidate  Set 

□  Merge  Demons  ( +  5  ‘MergeDemons) 

>  Method  Specific  Rules.  ‘MergeDemons 
Method  Ordering:  MergeDemons(  +  5) 

Step  6.8:  Equivalence  triggers 

Candidate  Set 

□  Anehorl  ( ♦  2  ‘Anchorlc) 

□ Anchor2 

>  Method  Specific  Rules:  ‘Anchorlc 
Method  Ordering:  Anehorl (* 2),  Anchor2(-) 

Comment:  Note  that  the  selection  rule  • Anchorlc  focuses  the  user's 
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D.6  Map  Demons 


attention  In  tha  right  ptaca.  tha  body  ot  SWITCH JS.EMPTY.  Cur  rant ly , 
the  user  is  required  to  carry  on  from  hero  In  regards  to  tha  evaluation  ot 
promising. 

Step  6.9:  Reformulate  switch .is.empty  as  expression 

Candidate  Set 

□  ReformulateDerivedRelation  ( *  2  'ReformulateDerivedRelation) 

>  Method  Specific  Rules:  ‘ReformulateDerivedRelation 
Method  Ordering:  Ref  ormulateOe  rived  Relation!  ♦  2) 

Step  6.1 0:  Unfold  switch.is.empty  in  trigger 

Candidate  Set 

□  ScatterComputationOfDerivedRelation  (♦  5  *ScatterComputationOfDerivedRelation) 

>  Method  Specific  Rules:  ‘ScatterCompuiationOfDerivedRelation 
Method  Ordering:  Scatte rComputat ionOf De ri vedRelat ion( * 5) 

Step  6.11:  Reformulate  existential  as  universal 

Candidate  Set 

□  ReformulateExiatentialTrigger  (  +  2  ‘ReformulateExiatentialTrigger) 

>  Method  Specific  Rules:  ‘ReformulateExiatentialTrigger 
Method  Ordering:  Ref ormulateExietentialT rigge r(  +  2) 

Step  6.12:  Equivalence  two  declarations 

Candidate  Set  (Problem  Solving  Abridgement) 

□  Anchorl  (  +  2  ‘Anchorla)  (<  EquivVaral) 

O  Anchor2  (  +  2  *Ar»chor2a)  (>  EquivVaral) 

>  Method  Specific  Rules:  ‘Anchorla,  *Anchor2a 

>  Ordering  Rules:  EquivVaral 

Method  Ordering:  Anehor2< ♦  2),  Anchorl ( ♦  2) 

Step  6.1 3  :(user)  Mfifimisrouted.package.reached.bin 
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Candidate  Set 

□  CD:  CaaifyDemon  ( +  2  CaaifyComplexConatruct)  ( ♦  2  ‘CaaffyDemoni) 
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□  MapByConaolidation 

*  MBCl:  02  bound  to  releaae.paekage.into.network  ( + 1  *MBC1) 

*  MBC2  02  bound  to  package.entering.awitch  ( ♦ 1  *MBC1) 

*  MBC3  02  bound  to  packaga.antering.btn  { +  1  *M6C1) 

*  MBC4: 02  bound  to  package.leaving.awitch  ( ♦  1  *MBC1) 

*  MBC5: 02  bound  to  package.leaving.bin  (  +  1  *MBC1) 

’  MBC6  02  bound  to  init.memo  ( ♦  1  *MBC1) 

*  MBC7:  02  bound  to  miarouted  .package.reached.bin 

’  MBC8:  D2  bound  to  create  .package  (-2  *MBC4)  ( ♦  i  *MBC2) 

*  MBC9;  02  bound  to  movej>ackage  (-2  ‘MBC4)  ( ♦  i  *MBC2) 

□  UD:  UnfoldOemon  ( ♦  1  ’Untold  Demon) 

>  Method  Specific  Rules:  ’ Casify Demon  1,  *MBCl,  *MBC2,  *MBC4,  *UntotdDemon 

Method  Ordering:  CD(  ♦  4),  {MBC1(  +  1),  MBC2( ♦  1).  MBC3(  + 1).  MBC4(  + 1),  MBC5(  ♦  1),  MBC6(  +  1). 
UD(  +  1)} 

Step  6.14:  Casify  misrouted.package.reached.bin 

Candidate  Sat 

□  CaeifyConjunctiveTrigger  (  +  2  ’CaaityConjunctiveTrigger) 

>  Method  Specific  Rules :  ‘CasHyConjunctiveTrigger 
Method  Ordering:  CaaifyConjunctiveTrigger(  +  2) 

Step  6.15:  Map  misrouted  .package_located_at.bin 
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Candidate  Set 

□  CO:  Caaify  Demon 

□  MapByConsolidation 

*  MBCl :  02  bound  to  releaae.package.into.network 


*  MBC2  D2  bound  to  package.entering.switch 

*  MBC3: 02  bound  to  packaga.antering.bin  ( *  2  *MBC8) 

*  M6C4: 02  bound  to  packaga.iaaving.switeh 

*  MBC6  02  bound  to  package.leaving.bin 


0.6  Map  Demons 


PAGE  351 


*  MBC6  D2  bound  to  init.memo 

*  MBC7:  D2  bound  to  miarouted.packaQe.reaehed.bin 

*  MBC8:  D2  bound  to  ereatejMCkage  (-2  *MBC4)  ( 4 1  *MBC2) 

*  MBC9: 02  bound  to  move .package  (-2  *MBC4)  ( ♦  i  *MBC2) 

□  UD:  UnfoldDemon  ( 4 1  'Untold  Demon) 

>  Method  Specific  Rules:  'MBC2,  *MBC4,  *MBC6,  'UnfoldDemon 

Method  Ordering:  MBC3( 4 2).  UD<  4 1),  (MBCI(-).  MBC2(-).  MBC4(-).  MBC5(-),  MBCS(-).  MBC7(-)} 

Step  6.1 6:  Consolidate  misroutedj>ackage.iocated.at.bin  and 

Candidate  Set 

D  MergeD emons  ( 4  5  'MergeOemona) 

>  Method  Specific  Rules:  'MergeOemona 
Method  Ordering:  MergeDemone(4  5) 

>  Action  Ordering  Rules:  TriggersAlmottEquiv 

Step  6.17:  Equivalence  declaration  lists 

Candidate  Set 

□  A1:  Anchorl 

□  A2:  Anchor2 

□  ECS:  EquivalenceCompoundStructures2  (4  2  *ECS2) 

>  Method  Specific  Rules:  *ECS2 
Method  Ordering  ECS2(4  2) 

Step  6.18:  Equivalence  bin.reached  and  bin 

Candidate  Set 

□  Anchorl  ( 4  2  'Anchorla}  (>  EquivVaral) 

□  Anchor2  ( 4  2  ' Anchor2a)  (<  EquivVaral) 

>  Method  Specific  Rules:  'Anchorla,  'Anchor2a 

>  Ordering  Rules:  EquivVaral 

Method  Ordering:  Anchorl (4  2),  Anchor2(4  2) 
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Step  6.1  9:(reposfed)  Equivalence  declaration  lists 

Candidal*  Sat 

□  A1:  Anchorl 

□  A2:  Anchor2 

□  ECS:  EguivalenceCompoundStructurea2 

□  ANV:  AddNewVar  ( ♦  2  “AddNewVar) 

>  Method  Specific  Rules:  “AddNewVar 
Mathod  Ordarino:  ANV(  +  2) 

Step  6.20:  Map  misrouted.package.destination.set 

Candidate  Sat 

□  CD:  CaaifyDemon 

□  MapByConaoiidation 

*  MBCi :  D2  bound  to  releaae.package.into.network  ( *  ^  *MBCl) 

*  MBC:2  D2  bound  to  package.entering.awitch  ( + 1  “MBCi) 

*  MBC3.  D2  bound  to  package.entering.bin  ( ♦  1  “MBCI) 

*  MBC4:  D2  bound  to  package.leaving.awitch  ( 4  1  “MBCI) 

*  MBC5.  D2  bound  to  package.leaving.bin  ( ♦  1  *MBC1) 

*  MBC6:  D2  bound  to  init.memo  ( 4  1  “KCC1) 

*  MBC7:  D2  bound  to  miaroutad.packaga.raachod.bin 

*  MBC8:  D2  bound  to  craatejpackaga  (-2  *MBC4)  ( + 1  *MBC2) 

*  MBC0:  D2  bound  to  mova.package  (-2  “MBC4)  ( *  i  *MBC2) 

□  UD:  Untold  Damon  (  + 1  “UnfoldDamon) 

>  Method  Specific  Rules:  “MBCI,  *MBC2,  “MBC4,  “UnfoldDamon 

Mathod  Ordarino:  {MBC1< 4  1),  MBC2(  ♦  1),  MBC3<  4 1),  MBC4(  ♦  1),  MBC5(  ♦  1),  MBC8<  4 1),  UD( 4 1)} 
Comment:  See  63 

Step  6.21 :  Unfold  misrouted.package.destination.set 

Candidate  Sat 

□  ScattarComputationOfDemon  ( 4  5  *SCOD) 
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Appendix  E 
Goal  Descriptors 


In  this  Appendix,  we  will  present  the  set  of  goal  descriptors  that  make  up  Glitter’s 
development  vocabulary.  We  have  attempted  to  define  a  general  set  of  descriptors,  distilling 
the  essential  semantics  of  a  development  goal  and  avoiding  special  cases.  For  instance,  one 
of  the  goals  of  the  language  is  Remove.  This  goal  takes  as  an  argument  an  arbitrary  program 
structure.  We  do  not  define  a  separate  goal  for  removing  particular  structures: 
RemoveRelation,  RemoveDemon,  etc. 

With  each  descriptor  will  be  given  a  textual  description  followed  by  several  examples  of  the 
descriptor  in  use.  Heading  each  example  section  is  a  list  of  the  steps  in  the  router 
development  (appendix  C)  where  the  goal  is  explicitly  used;  goals  trivially  satisfied  in  the 
router  development  (i.e.  achieved  within  the  posting  state)  do  not  show  up  explicitly  either 
here  or  in  the  development.  In  some  cases,  we  have  taken  examples  from  other  developments 
including  the  following: 

1.  Text  preprocessor.  The  first  development  attempted  using  Glitter.  The  problem  is 
the  optimization  of  a  procedure  which  cleans- up  a  message  body  before  sending 
it  through  an  analyzer.  Portions  of  the  development  are  reported  in[Balzer 
76,  Wile  61a].  This  development  will  be  denoted  as  Text  Preprocessor. 

2.  Line  drawing  algorithm.  This  hand  development  of  a  graphics  line  drawing 
algorithm  was  reported  by  Sproull  [Sproull  81].  It  offers  a  slightly  different  view  of 
several  development  concepts.  We  will  denote  this  development  as  Line  Draw. 


3 


$ 


3.  Heap  sort  development.  No  research  Into  automatic  program  development  would 
be  complete  without  at  least  one  sort  example.  This  one  is  taken  from  some 
unpublished  notes  of  Tim  Standish.  We  will  denote  this  development  as  Heap 
Sort. 

We  use  these  different  examples  to  provide  explanation  variety;  only  the  Package  Router  and 
Text  Preprocessor  have  been  developed  using  Glitter. 

Finally,  we  will  simplify  the  goal  posting  notation  to  that  used  in  Appendix  B. 
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E.l.  Casify 

Casify(C|consfrucf ) 

Achievement  Condition:  C  is  replaced  with  {Cr..Cn} 

Goal  Description:  this  is  the  driver  behind  divide- and -conquer  strategies.  A  complex 
structure  can  often  be  broken  out  into  several  simpler  components.  However,  while  the  case- 
analysis  concept  is  a  powerful  one,  the  real  insight  comes  from  selecting  the  right  partitioning 
elements.  The  user  is  generally  relied  on  to  make  this  selection. 

. Examples  of  Use . 

Router  References:  4.8, 4.1 1 , 4.14, 5.18,  5.19, 6.2,  6.14 

Example  A 

Router  Reference :  4.11 

Development  context:  section  B.4  of  the  router  development  points  out  the  problem  of 
working  with  complex,  temporally-modified  predicates.  At  step  4.10,  the  following  constraint  is 
marked  for  mapping: 

reoui  re  ( -  ( package :  located_at  ■  switch 
and 

SWITCH.SET_WRONG.FO  R.P  A  C  K  A  GE  ( switch,  package ) ) 
after  ThisEvent 

In  this  example,  ThisEvent  can  be  interpreted  as  the  current  time.  Abstractly,  we  have 
reaui re  P  from  now  on) 

Step  4.11  attempts  to  simplify  the  mapping  problem  by  suggesting  that  the  single  constraint 
be  broken  out  into  several  cases.  Once  the  Casify  goal  is  posted,  the  remaining  problem  is 
choosing  the  best  case-analysis  method.  In  this  example,  a  method  is  chosen  which  casifies 
around  some  future  event  E  (chosen  by  the  user): 
reoui re  P  from  now  until  E); 

require  p  diming  e); 

require  P  after  E); 
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The  time  requirement  is  split  into  the  period  before,  during  and  after  E.  Of  course,  the 
effectiveness  of  casifying  here  depends  on  the  correct  choice  of  E.  In  this  case  E  was  chosen 
as  the  time  the  package  was  located  at  the  switch,  allowing  is  to  straightforwardly  get  rid  of 
the  first  and  third  cases  and  center  our  attention  on  the  second,  linchpin  requirement. 


Example  B 

Router  Reference:  5.18 


Development  context:  while  the  use  of  abstraction  may  lead  to  a  more  perspicuous  initial 
spec,  the  development  may  require  specific  cases  to  be  broken  out.  Such  is  the  case  in  step 
5.18:  an  abstract  (a.k.a.  Super)  type  sensor  has  been  defined  in  the  initial  spec.  Further,  a 
demon  has  been  defined  that  triggers  on  a  package  leaving  a  sensor. 


demon  PACKAGE_LEAVING_SENSOR  (package,  sensor) 
trigger  -package :  located.at  ■  sensor 
response  null : 


In  section  5  of  the  development,  it  becomes  useful  to  know  which  type  of  sensor  (switch  or 
bin)  a  package  is  leaving.  The  case-analysis  method  chosen  hinges  on  the  subtypes  of 
sensor,  producing  two  new  demons: 


demon  PACKAGE_LEAVING_SWITCH(package,  switch) 
triaqer  -package : cocated.at  ■  switch 

rflsp.msfi  null ; 


demon  PACK  AGE  J.EAVING.BIN {package,  bin) 
trigger  -package : located.at  ■  bin 
response  null : 


Example  C 

Router  Reference :  6.13 
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Development  context:  the  triggering  of  a  constraint  or  demon  may  depend  on  the 
occurrence  of  any  one  of  a  number  of  events,  it  is  sometimes  useful  to  break  out  the  events 
into  individual  cases,  and  treat  each  one  separately.  Such  is  the  case  in  step  6.13,  the 
mapping  of  the  demon  MISROUTED_PACKAGE_REACHED.BIN  (note  that  Gist  variable 
convenetions  do  not  allow  bin.  reached  and  bin. intended  to  be  boudn  to  the  same  physicla 
bin): 


demon  MISROUTED_PACKAGE_REACHED_BlN(pacfcage,  bin.reached,  bin.intended) 
trigger  package : located. at  ■  bin.reached 
and 

package :  destination  ■  bin.intended 
response  invoke  MISROUTED_ARRIVAL(D/n.reacfted,  bin.intended) 


The  necessary  conditions  for  triggering  this  demon  are  either  1)  a  package  enters  a  bin  or  b) 
the  destination  of  a  package  is  set65.  Breaking  the  demon  into  these  two  cases  facilitates 
further  development:  the  second  case  cannot  be  satisfied  and  hence  only  the  first  need  be 
considered  (in  its  now  simplified  form): 


demon  MISROUTED_PACKAGEJ.OCATED_AT_BIN(pacfcage,b/n.reac/)ed,b/n-/nrendecO 
trigger  package : located.at  *  bin.reached 
MSP, pm 

i£  (package: destination  ■  bin.intended 
at  ThisEvent ); 

then  invoke  MISROUTED_ARRIVAL(0/'n.reached,  bin.intended) ; 

demon  MISROUTED_PACKAGE_DESTINATION_SET(pacfcape,b/n.reached,b/7i-/mendecO 
trigger  package : destination  ■  bin.intended 
response 

if  ( package : located. at  ■  bin.reached 
at  ThisEvent) ; 

then  invoke  MISROUTED_ARRIVAL(D/n.reached,  bin.intended) ; 


flfi 

That  these  two  events  cannot  happen  simultaneously  Is  something  that  must  be  shown  Ister  in  the  development. 
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Example  D 

Router  Reference:  Text  Preprocessor 


Development  context:  a  portion  of  the  Text  Preprocessor  is  given  below.  The  following 
actions  are  performed  on  a  sequence  of  characters  Text: 

□  ►1  If  the  current  character  is  a  linefeed  then  replace  it  with  a  space. 

□  >2  If  the  current  character  is  not  an  alphanumeric  or  space  then  remove  it  from 
Text. 

□  ►  If  the  current  character  is  redundant  (i.e.  a  space  preceded  by  a  space)  then 
remove  it  from  Text. 


loop  Char  la  Text 
&  begin 

►  j  If  linefeed  (Char  then  invoke  REPLACEf  Char,  space.  Text) ; 

►2  If  ~(alphanumeric(Char)  ga  space(Char)) 

then  invoice  REMOVE( Char,  Text) ; 

►3  if  redundant  (Char,  Text) 

then  invoke  REMOVE  (Char,  Text); 

end  . . . 


By  using  the  Casify  goal,  we  can  add  some  structure  which  will  facilitate  further  optimization. 
We  can  embed  the  body  of  the  loop  within  each  case  of  a  mutually-exclusive  case  statement 
(given  that  the  user  supplies  the  necessary  partitioning): 
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loop  Char  Iq.  Text  do 
mux-case  Char 
linefeed:  begin 

if  linefeed ( Char) 

then  invoke  REPLACE( Char,  space,  Text) ; 
if  -(alphanumeric  Char)  ££  spac  e(Char)) 
then  invoke  REMOVE ( Char,  Text) ; 
if  redundant ( Char,  Text)  then  invoke  REMOVE ( Char,  Text) ; 
end 

apace:  beoin 

if  linefeed  (Char) 

then  invoke  REPLACE(Cftar,  space,  Text) ; 
jf  -(alphanumeric (Char)  £_r  space( Char)) 
then  invoke  REMOVE( Char,  Text) ; 
if  redundant  (Cher,  Text)  then  invoke  REMOVE  (Char,  Text); 
end 

alphanumeric:  begin 

if  linefeed( Char) 

then  invoke  REPLACE  (Char,  space,  Text) ; 
if  -(alphanumeric (Char)  ££  space( Char)) 
then  invoke  REMOVE(Char,  Text)  ; 
if  redundant  {Char,  Text)  then  invoke  REMOVE  ( Char,  Text) ; 
end 

otherwise:  beoin 

IX  linefeed  (Char) 

then  invoke  REPLACE( Char,  space.  Text) ; 
if  -(alphanumeric Char)  ft£  space(Char)) 
then  invoke  REMOVE ( Char,  Text) ; 
if  redundant( Char,  Text)  then  invoke  REMOVE( Char,  Text) ; 

6ntf-mu*-cas9; 


After  further  optimization,  we  have 
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Tooo  Char  la  Text  do 
mux-case  Char 

linefeed:  vf  predecessor(space,  Char,  Text) 

then  invoke  REMOVE  (Char,  Text) 
else  invoke  REPLACE( Char,  space,  Text) 
space:  vf  predecesso r(space,  Char,  Text) 

then  invoke  REMOVE  (Char,  Text) ; 

alphanumeric:  ; 

otherwise:  invoke  REMOVED  Char,  Text) 


PAGE  392 


GOAL  DESCRIPTORS 


E.2.  ComputeSequentially 

ComputeSequentially(Ci|consfri/cf,  C2|cons/rucf) 

Achievement  Condition:  Cl  computationally  precedes  C2 

Goal  Description:  C2  is  an  action  that  has  the  potential  of  effecting  Cl.  We  want  to 
guarantee  that  C2  does  not  effect  Cl . 


Examples  of  Use 


Router  References :  2.6 


Example  A 

Router  Reference :  2.6 


Development  context: 


demon  NOTI CE_NE W_P A C K AGE_ AT_SO U RCE ( package ) 
triooer  package :  located.at  «  the  source 
respoase 
atomic 

►«  update  prev_package  ia  PREVIOUS.PACKAGE(S) 

la  LAST.PACK  AGE(  • ) ; 

►2  update  last_package  ia  LAST_PACKAGE($) 

la  package 

and  atomic; 

demon  RELE A SE_P ACK AGEJNTO.NETWOR K ( package. new) 
trigger  package. new: located.at  ■  the  source 

rftSPQB.5.0 

begin 

►,  it  PREVIOUS_PACKAGE( • ) :  destination  *  package. new :  destination 
then  WAIT[]; 

update  :located_at  al  package.new  la  ( the  source) : source.outlet 

and; 


Here,  relation  PREVIOUS.PACKAGE  is  updated  to  LAST_PACKAGE(*).  We  want  to  insure 
that  a  subsequent  reference  to  PREVIOUS.PACKAGE  can  be  replaced  with 
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LAST.PACKAGE,  i.e.  that  the  value  of  LAST.PACKAGE  has  not  changed  between  the  time 
PREVIOUS.PACKAGE  was  updated  and  the  time  it  is  referenced.  If  there  exists  an  action 
that  changes  LAST.PACKAGE  between  these  times,  we  want  the  action  executed  after  the 
reference.  Above,  ►1  points  to  the  update  of  PREVIOUS.PACKAGE,  points  to  the  change 
to  LAST.PACKAGE  which  must  be  moved,  and  >3  to  the  reference. 

Example  B 

Router  Reference:  Text  Preprocessor 


During  the  development  of  the  text- preprocessor,  a  state  is  reached  containing  the  following 
program  fragment: 


begin 

►  j  invoke  REPLACE ( Char  newspace  Text)  ; 

►  2  11  predecessor  {space,  Char,  Text)) 

then  invoke  REMOVE  {Char  Text) 

end 


That  is,  replace  the  current  character  Char  with  a  space  (►,).  If  the  preceding  character  is  a 
space  then  remove  the  current  character  (>2).  In  only  some  cases  we  will  be  replacing  Char's 
value  only  to  remove  it  entirely  later,  i.e.  those  cases  where  Char's  predecessor  is  a  space.  A 
general  method  says  that  if  you  can  compute  two  actions  sequentially  and  show  the  first  is 
superseded  by  the  second  then  you  can  get  rid  of  the  first. 


To  achieve  the  ComputeSequentially  goal,  we  must  distribute  the  call  on  REPLACE  within  the 
conditional: 


frealu 

if  predecessor( space,  Char,  Text) 
then  begin 

►  .  invoke  REPLACE(  Char  newspace  Text) ; 

invoke  REMOVE( Char  Text) 
end 

else  invoke  REPLACE  {Char  newspace  Text) ; 
end 


Finally,  we  can  remove  the  first  call  to  REPLACE  >y 
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begin 

if  pred«cessor( space,  Char  Text) 
then  invoke  REMOVE(C/iar  7exf) 
else  invoke  REPLACE  ( Char  newspace  Texl) ; 
end 


E.2  ComputeSequentially 
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E.3.  Equivalence 

Equivalence(  Cl  Icons  truct,  C2\construct ) 

Achievement  Condition:  Cl  is  structurally  equivalent  to  C2. 

Goal  Description:  Equivalency  here  is  based  on  structural  or  pattern-match  semantics  (see 
also  the  Lisp  function  equals):  if  Cl  and  C2  are  two  expressions  in  one-to-one 
correspondence,  then  Cl  and  C2  are  equivalent.  Note  that  in  achieving  this  goal,  there  is  no 
requirement  that  either  Cl  or  C2  remain  anchored;  both  may  change  into  some  new  common 
form. 

. Examples  of  Use . 


Router  References :  1.15,  2.10,  2.11, 4.5,  6.8, 6.12, 6.17, 6.18,  6.19 

Example  A 

Router  Reference:  4.5 

Development  context:  when  attempting  to  consolidate  two  structures,  generally  one  or 
more  of  the  components  of  each  must  be  made  equivalent.  In  consolidating  the  two  demons 
at  step  4.4,  we  find  we  must  equivalence  the  two  triggers  (►,,  ►g)  of  the  two  demons: 


demon  SET.SWITCH (switch) 
trigger  RANDOM() 

response  • •  • 


demon  SET  SWITCH  WHEN_HAVE_CHANCE(sw/fch ,  package) 

►  trigger  ( package  «  fi  rstf  PACKAGES  DUE  AT  SWITCHf »  .switch) ) 
*  and 

SWITCH_IS_EMPTY  { switch ) ) 
response  ... 


In  this  example,  *2  will  be  held  constant  (anchored)  and  ►1  changed  to  match  it.  This  strategy 
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was  chosen  because  of  the  general  ease  with  which  RANDOM  can  be  specialized.  After 
consolidation  we  have 


demon  SET_S  WITCH  (switch,  package 

triooer  ( package  «  Iiril(PACKAGES.DUE_AT_SWITCH(*,sw/fch)) 
and 

SWITCH  JS.EMPTY  ( switch ) ) 
response  . . . 


Example  B 

Router  Reference :  2.10,2.11 

Development  context:  equivalencing  two  compound  structures  is  a  frequently  occurring 
goal.  For  instance,  in  step  2.10  we  wish  to  make  two  demon  argument  lists  equivalent: 
(package. new)  is  the  first  list  and  (package )  the  second.  A  useful  method  for  achieving  this 
goal  employs  a  divide-and-conquer  strategy  by  attempting  to  equivalence  each 
subcomponent  in  a  pairwise  fashion.  This  leads  to  the  equivalencing  of  package. new  and 
package  in  step  2.11.  Since  each  of  these  are  primitive  components,  other  methods  will  be 
employed  (e  g.  anchoring,  renaming). 
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Facto  r(  T|  lemp/afe,  C[  construct ) 

Achievement  Condition:  Factor  all  occurrences  of  T  within  C 

Goal  Description:  As  a  development  progresses,  information  tends  to  spread  throughout 
the  program.  At  certain  points  it  is  organizationally  useful  to  regroup  (factor)  common 
structures. 

The  factor  goal  has  two  parameters:  a  template  and  a  context.  The  template  is  a  pattern  with  a 
special  mechanism  for  marking  formal  parameters  in  the  resulting  definition.  The  context 
bounds  the  area  in  which  the  template  will  be  matched66. 

. Examples  of  Use . 


Router  References:  6.5 


Example  A 

Router  Reference :  6.5 


Following  is  a  portion  of  the  package  router  development,  abstracted  somewhat  here  for 
readability. 


it  P 

then 

update  packagesjdue  gl  PACKAGES_DUE_AT_SWITCH(sw/tch.currenf,$ 
to  PACKAGES_DUE_AT_SWITCH(swifc/J.currenf,*)  minus  package 


a  159 

loop  Q  do 

update  packagesjlue  gl  PACKAGES_DUE_AT_SWITCH(swjfc/7,$) 
to  PACKAGES..DUE_AT_SWITCH($w/fc/>,*)  minus  package; 


) 


Using  the  template 


66 

The  Isolate  goal  can  be  viewed  as  a  special  case  of  the  Factor  goal  where  the  context  is  exactly  the  expression 
to  be  factored. 
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update  packages  jiue  gf  PACKAGES_DUE_AT  S WITCH (  # switch*1 ,  S) 
P  ACK  AGES_DUE_AT_SWITCH(  # switch , •  )  minus  # package 


we  can  factor  the  two  updates  into  a  single  new  procedure: 


II  P 

then  invoke  TRIM_PACKAGES_DUE_AT_SWITCH(pac/cage, 

switch.current) 

else 

loop  Q 

SlSL  invoke  TRIM_P ACK AGES_DUE_AT_SWITCH (package,  switch) 


procedure  TRIM_PACKAGES_DUE_AT_SWITCH (package ,  switch) 

update  packages  jiue  g£  PACKAGES_DUE_AT_SWITCH(sw/fch,S) 
to  PACKAGES_DUE_AT_SWITCH($w/fch,*)  minus  package ; 


The  usefulness  of  factoring  here  will  become  apparent  later  in  the  development  when 
maintenance  code  must  be  introduced  at  each  change  to  PACK  AGES_DUE_AT_S  WITCH, 
before  occurring  in  two  locations,  but  now  only  one. 


Example  B 

Router  Reference:  Heap  Sort 


The  following  is  a  portion  of  an  intermediate  state  in  the  development  of  a  heap  sort  algorithm 
suggested  by  Tim  Standish: 

procedure  SiftUp(/,n) 
declare  j:  integer; 
begin 

If  2 mi>n  then  Exit  el  se  /  :»  2*/; 
if  2 *i<n  then  if  C(2*/+1)>C(/)  then  j  :■  2*/+l; 
it  C(/)>C(/)  then 
begin 

Exchange(C(/)  C(/)); 
invoke  SiftUpO  n) 

And: 


Factoring  2*/  gives  us 


67 


In  •  factor  template,  ftypa.name  signifies  a  formal  parameter.  The  #  will  be  removed  in  the  definition. 
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Procedure  SlftUp(/.n) 
declare  j:  integer; 
relation  dou ble.i ( V | integer) 
definition  V  «  2*i; 
beoin 

if.  double_i(*)>n  then  Exit  else  j  :■  double_i(*): 
i i  double  f(*)<n  then  if  C(doubleJ(*)+l)>C(/)  then  j:«doubleJ(*)+l; 

ii  c(j)>c(i)  man 

beoio 

invoke  Exchange(C(/)  C(/)); 
invoke  SiftUpO  n ) 
end : 


Further  development  yields 


procedure  SiftUp(/,n) 
declare  integer; 
begin 
j  :*  2*/; 
if  j>n  then  Exit; 

if  j<n  then  if  C(j+l)>C(j)  then  j  :■/+ 1; 
if  C (y ) >C( /)  then 

bag  In 

invoke  Exchange (C(y)  C(/) ) ; 
invoke  SiftUpO  n ) 

ana; 
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E.5.  Flatten 

Flatter^  C|co  nstruct ) 

Achievement  Condition:  No  procedure  calls  or  derived  relation  references  exist  in  C. 


Goal  Description:  The  Flatten  goal  can  be  used  for  several  different  purposes: 

□  To  explicate  dependencies.  For  example,  before  maintaining  a  derived  relation  R, 
we  must  determine  the  set  of  base  relations  that  R  depends  on  (is  defined  in 
terms  of).  A  simple  way  to  determine  the  base  set  is  to  make  all  base  relations 
explicit  within  R’s  body,  i.e.  Flatten  any  derived  relations  within  R's  body. 

□  To  optimize.  In  general,  optimizations  cannot  be  carried  out  across  definitional 
boundaries.  If  C  is  shown  to  be  crucial  to  the  performance  of  the  program  as  a 
whole,  then  we  may  want  to  Flatten  the  procedure  calling  structure  within  C  to 
allow  local  optimization  to  be  carried  out. 

The  methods  used  to  flatten  a  context  rely  on  either  maintaining  or  unfolding  defined  objects. 

Hence,  Flatten  could  be  described  as  one  or  more  postings  of  Untold  and/or 

Maintainlncrementally ,  making  Flatten  a  vocabulary  enriching,  but  unnecessary  goal. 


Examples  of  Use 


Router  references:  1.8,  5.3,  5.7 


Example  A 

Router  Reference :  1.8 


Development  context:  the  goal  of  step  1.7  is  the  incremental  maintenance  of  the  derived 
relation  PREVIOUS.PACKAGE. 


relation  PREVIOUS_PACKAGE(prev_pacfcflpe  |  package) 
definition  prev .package  • 

(A  package. previous  1 1 

package.previous  Immediate! v  <  1  ast ( PACK AGES_EVER_AT_SOURCE( • ) ) 
Hi  PACKAGES.EVER_AT_SOURCE(*)); 
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To  maintain  PREVIOUS.PACKAGE,  we  must  determine  when  it  changes,  i.e.  what  relations 
it  depends  on.  In  this  case,  there  is  one:  PACK AGES_EVER_AT_SOURCE  (►.,).  However, 
PACKAGES_EVER_AT_SOURCE  is  a  derived  relation  itself  which  may  be  defined  in  terms  of 
still  further  relations.  To  explicate  PREVIOUS.PACKAGES’s  base  relations,  a  Flatten  goal  is 
posted  at  step  1.8.  Note  that  if  PACKAGES.EVER.AT.SOURCE  was  defined  in  terms  of  still 
further  derived  relations,  these  in  turn  would  have  to  be  flattened  (see  step  5.3). 


PAGE  372 


GOAL  DESCRIPTORS 


E.6.  Globalize 

Globalize(C|consfrt/cf ) 

Achievement  Condition:  C  is  to  be  moved  out  of  the  local  context:  local  connections 
have  been  snipped;  C  is  not  part  of  an  atomic. 

Goal  Description:  Much  work  in  a  development  involves  moving  structures  from  one  place 
to  another,  in  pulling  some  piece  of  code  out  of  a  particular  context,  we  must  make  sure  of 
several  things: 

□  Any  references  to  locally  scoped  variables  within  C  should,  if  possible,  be 
removed.  If  one  or  more  variables  resist  removal,  then  C  must  be  encapsulated 
and  an  argument  defined  for  each  local  variable  remaining. 

□  C  cannot  be  part  of  an  atomic.  The  statements  of  an  atomic  are  treated  as  an 
indistinguishable  action  and  cannot  be  spread  out  individually. 

. Examples  of  Use . 


Router  Reference:  1.4,  5.12,  5.16 

Example  A 

Router  Reference :  1.4 

Development  context:  at  step  1.3,  a  goal  is  posted  to  Isolate  a  derived  object  (►.,)  found  in 
the  demon  RELEASE_PACK  AGEJNTO.NETWORK.  The  derived  object  makes  reference  to 
the  variable  package. now,  locally  scoped  by  the  demon. 


E.6  Globalize 
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demon  RELEASE_PACKAGE_INTO_NETWORK(  package.new) 
trigger  package. new: located. at  *  the  source 
response 
beo  i  n 

il 

►  j  ( the  package. previous  |  | 

package. previous  immediate! v  before  package. new 
Ml  P ACK AGES_EVER_AT_SOURCE( • ) 

):  destination  *  package. new:  destination 
littH  WAIT[] ; 

update  :located.at  gf  package.new  ig  (igg  source) :  source.outlet 
Md; 


If  the  reference  to  package.new  is  not  eliminated,  the  resulting  derived  relation  must  include  it 


as  an  argument. 


Example  B 


Router  Reference :  5.12 

Development  context:  in  this  example  we  are  trying  to  move  a  piece  of  code  >2  out  of  a 
demon  which  is  part  of  the  environment  (see  Purify,  section  E.10). 


demon  CREATE_PACKAGE( ) 
trigger  RANDOM( ) 
re^>P..n_S.e 
atomic 

create  package.new  |  | 

package.new: destination  *  g  bin  and 
package.new : located_at  *  the  source ; 

►  2  loop  ( switch  1 1 

MEMO_LOCATION_BIN  ( switch ,  package. new :  DESTINATION ) ) 
jig  update  packagesjue  gf  PACKAGES_DUE_AT_SWITCH(sw/fch,$) 
to  PACKAGES_DUE_AT_SWITCH(sw/fch,*)  concat  <package.new> 
end  atomic : 


•Tele, 
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E.7.  Isolate 

ISOlate(  E|express/on ) 

Achievement  Condition:  Replacement  of  E  with  reference  to  defined  relation. 

Goal  Description:  This  goal  reformulates  some  local  embedded  expression  into  a  global 
one.  This  is  generally  the  first  step  in  moving  the  expression  to  a  location  where  it  can  be 
further  optimized.  Note  that  the  Isolate  goal  is  a  special  case  of  Factor  where  the  template 
must  be  a  value  returning  expression  and  the  context  is  the  expression  itself.  In  this  sense,  it 
is  equivalent  to  a  Fold  in  apllicative  Inaguage  development  systems  (e.g.  [Darlington  81]).  We 
believe  it  occurs  frequently  enough  as  a  speical  case  of  factoring  to  be  broken  out  separately. 

. . Examples  of  Use . 


Router  References :  1.3,  1.17, 3.3 

Example  A 

Router  Reference :  3.3 

Development  context:  in  section  3,  we  are  concerned  with  the  removal  of  the  relation 
LAST.PACKAGE:  only  the  destination  of  the  last  package  is  needed.  The  general  strategy 
used  is  to  remove  all  references  to  the  relation,  thus  making  the  definition  removable.  There  is 
only  one  reference  to  the  relation: 

il  LAST_PACK AGE(  • ) :  destination  *  package. new :  destination 
then  invoke  WAIT(); 

By  posting  an  Isolate  goal  on  the  retrieval  of  the  last  package’s  destination,  we  can  make  this 
expression  global. 

•  •  * 

11  LAST_PACK AGE_DESTIN ATION(  • )  *  package. new :  destination 
then  InYPkC  WAIT( ) ; 

relation  LAST_PACKAGE_DESTINATION(/asr_desf/n8f/on|  bin) 
definition  last_destination  «  LAST_PACKAGE(*): destination; 


§ 

*  m 


's  i 
•  . 


.'•'.1-1  '-in-  IL’ 
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The  global  computation,  in  the  form  of  a  derived  relation,  can  now  be  moved  to  a  location 
where  further  optimizations  can  be  performed  (see  step  3.4). 

Example  B 

Router  Reference:  Line  Draw 

Development  context:  Sproull  presents  the  development  of  a  line  drawing  algorithm  which 
attempts  to  minimize  the  reliance  on  costly  arithmetic  operations  such  as  multiplication  and 
division.  We  will  view  the  use  of  such  operators  as  specification  freedoms  that  must  be 
mapped66.  We  are  given  the  following  portion  of  program  for  drawing  a  "straight  line" 
between  two  points  (0,0  and  dx,dy)  on  a  graphics  screen69: 


loop  x 


0  to  dx 


do  beoin 

y  :«  truncate( [dy/dx] 
DISPLAY (x  y) 
find: 


x  +  1/2) ; 


Our  goal  is  to  map  the  multiplication  operation  into  an  acceptable  operation  (e.g.  addition)  on 
the  final  implementation  hardware.  The  method  we  wish  to  use  replaces  the  multiplication  of 
the  loop  variable  by  a  constant  with  a  new  expression  only  using  addition  (as  residue,  it  leaves 
another  expression  involving  multiplication  that  can  be  mapped  later).  The  method  expects 
that  the  multiplication  has  been  isolated,  i.e.  it  cannot  work  on  embedded  expressions. 


68 

Note  that  Sproull's  development  is  the  algorithmic  optimization  type  that  we  have  disassociated  from.  However, 
the  freedom  mapping  view  makes  it  an  illustrative  example. 

60 

The  pseudo  Pascal  notation  is  Sproull's.  The  Gist  version  would  replace  variables  with  relations  and 
assignments  with  inserts  and  updates 
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Transformation  Remo  veMul  tipi  1  cat  Ion: 

loop  i  from  cl  c2 
do  beoin 

z  : *  c3  •  1 

&Q4; 


z  :■  (cl  -  1)  •  c3; 
loop  i  from  cl  ift  c2 
do  boo in 

z  :«  z  +  c3; 

4114: 


Using  isolation  leads  us  to  the  following  state  in  which  the  RemoveMultiplication 
transformation  can  be  applied: 


loop  x  from  0  to  dx 
do  beoin 

l  :•  [dy/dx]  *  x; 
y  :•  truncated  +  1/2); 
DISPLAY  (xy) 

444: 


Further  in  the  same  development,  we  reach  the  following  state: 


loop  x  from  0  1ft  dx 
do  begin 

s  :»  t  +  1/2; 
y  :«  truncate(s); 
DISPLAY  (x  y) 
t  :•  t  +  [dy/dx] 
404: 


The  goal  is  now  the  removal  of  the  variable  t.  Again  using  isolation,  in  this  case  the  reference 
to  f  in  the  computation  of  s,  we  get 


A-  .  VV  MW 


r.  v.  r J  AVWV  V  7V  v  VVVVV  >vj 
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relation  s|REAL  ■  t  *  1/2; 
/  :■  0; 

loop  x  from  0  jfl  dx 
do  beoin 

y  :«  truncate(s); 
DISPLAY  (x  y) 

1  :*  t  +  [dy/dx] 

find; 


Finally,  after  computing  s  at  each  place  it  changes  (see  the  goal  Maintainlncrementally)  we 


relation  s  |  real ; 

atomic 
t  :*  0; 
s  :*  0  +  1/2 
find  atomic 
loop  x  from  0  to  dx 
do  begin 

y  :«  truncate(s); 
DISPLAY  (xy) 
filfiOLifi 

1  :•  t  +  [dy/dx]; 
s  «  s  ♦  [dy/dx] 
find  atomic 
find; 


which  can  be  simplified  into 

relation  $  |  real ; 

$  :*  0  ♦  1/2 
loop  x  from  0  id  dx 
do  beoin 

y  :■  truncate(s); 
DlSPLAY(xy) 
s  «  s  +  [dy/dx] 

find; 


/WX*? 
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E.8.  Map 

Map(  C|  construe/ ) 

Achievement  Condition:  The  freedom  embodied  by  C  has  been  mapped  away. 

Goal  Description:  A  large  part  of  the  development  of  an  abstract  specification  involves 
finding  ways  to  remove  specification  freedoms  which  are  not  supported  in  the  implementation 
language.  What  is  considered  a  freedom  is  naturally  dependent  on  the  specification  language 
being  used  and  the  final  implementation  language.  The  following  are  Gist  specification 
freedoms:  derived-relations,  temporal  reference,  demonic  computation,  constraints  and  non- 
deterministic  selection  (see  section  5.2.1  for  further  discussion).  Depending  on  the 
implementation  language,  other  freedoms  might  include  recursi{n,  parallelism,  the 
associative  relational  data  base  and  even  multiplication  (see  example  B  in  section  E.7). 

. Examples  of  Use . 

Router  References:  1 .10, 4.1 , 4.3,  4.7, 4.9, 4.10, 4.12, 4.13, 4.15, 4.16, 4.18, 5.1 , 5.4,  5.5, 5.8, 
6.1, 6.3,  6.6, 6.13,  6.15, 6.20 

Example  A 

Router  Reference :  5.4 

Development  context:  LOCATlON_ON_ROUTE_TO_BIN  is  one  of  the  derived  relations 
found  in  the  specification: 

relation  LOCATION  ON  ROUTE  TO  B\N(  LOCATION  .BIN) 

d&HalLLan 

case  LOCATION  fif. 

BIN  m  LOCATION  ■  BIN ; 

RIPE  LOCATION.ON.ROUTE_TO.BIN  ( 

LOCATION: connection  to_swltch_or_bin.BIN) ; 

SWITCH  LOCATION_ON_ROUTE_TO_BIN ( LOCATION :  switch.outlet , BIN) ; 

SOURCE  ~  LOC ATION_ON_ROUTE.TO.BIN {LOCATION: sou rce_outlet.BIN) : 
end  case : 
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It  is  mapped  away  by  remembering  the  router  connections  explicitly: 


relation  MEMO_LOCATION.BIN (/ocaf/on ,  bin); 

demon  INITIALIZE_MEMO_LOCATION_BIN( ) 
triooer :  ( start  initialization _slate) 
response 
begin 

loop  B  |  BIN  insert  MEMO.LOC ATION.BIN (B,  B) ; 
loop  L  |  LOCATION  1 1 

MEMO_LOCATION.BIN (L,  B)  Md 
L  *  L2  :  CONNECTION  TO  SWITCH_OR.BIN 
dfl  insert  MEMO_LOCATION_BiN(l2,  B) ; 


nstraint  Dl  D_NOT_SET_S  WITCH_  WHEN_H  A  D_CH  ANCE 
always  prohibit  3  package, switch  j  J 
(package :  located. at  •  switch 
and 

SWITCH_SET_WRONG_FOR_PACKAGE(  switch, package) 
and 

(( package  •  f  i rstf PACKAGES  DUE  AT  SWITCH f  *  .switch)) 
and 

SWITCHJSJEMPTY (switch))  asof  everbeforeU  : 


The  method  employed  maps  the  constraint  into  a  demon  which  triggers  on  one  of  the 
conjunctive  arms  of  the  constraint,  and  requires  that  the  other  two  arms  not  hold.  The  trick 
here  is  choosing  which  arm  to  trigger  on,  i.e.  whcich  event  allows  the  others  to  be  avoided. 
The  choice  is  currently  left  ot  the  user.  The  new  demon  is 
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demon  SET_SWITCH_WHEN_HAVE_CHANCE(sw/?ch ,  package) 
trigger  ( package  *  Hr££( PACK AGES.DUE.AT.S WITCH (m, switch)) 
and 

SWITCH  JS.EMPTY  (switch ) ) 

response 

require  (-(package: LOCATED.AT  ■  switch 
and 

SWITCH_SET_WRONG_FOR_PACKAGE(sw/fch.pac*age)) 
from  ThisEvent 70 
until  -((package  • 

firsts  P  ACKAGES.DUE.AT_S  WITCH  (  •  .switch ) ) 
and 

SWITCH_IS_EMPTY(  sw//eh))  asof  everbeforel  1 


We  now  must  map  this  demon.  The  general  strategy  will  be  to  consolidate  this  demon  with  the 
SET.SWITCH  demon  which  controls  the  setting  of  switches.  Note  that  the  use  of  demons  as 
intermediate  mapping  forms  appears  useful  and  is  replected  in  the  selection  rule 
DemonsAreGood. 


Example  C 


Router  Reference:  4.18 


Development  context:  at  step  4.18,  the  update  of  a  switch’s  setting  is  still  in  non- 
deterministic  form: 

UPtifltS  *  SWITCH  SETTING  SlWItCh  switch  I  SWITCH^ OUTLET 

where  SWITCH  JS.EMPTY  (switch) 
and 

~SWITCH.SET_WRONG.FO  R.P  A  C  K  A  GE  ( switch, package ) ; 

The  method  employed  will  be  to  choose,  deterministically,  a  setting  that  does  not  violate  the 
attached  constraints: 


i.e.  the  trig  Bering  of  this  demon. 
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Update  :  SWITCH.SETTING  fil  switch  jp 

( pipe  ||  pipe  •  switch :  switch.outlet 
and 

LOCATION  J5N_ROUTE_TO_BIN(p/pe , 

package :  destination  ) ) ; 
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E.9.  Maintainlncrementally 

Maintainlncrementally(  P\d*fln*l-nlation) 

Achievement  Condition:  R  recomputed  eager//  (as  opposed  to  lazy  evaluation)  in 
terms  of  the  changes  to  the  value  upon  which  it  is  defined. 

Goal  Description:  A  derived  relation  R  is  defined  in  terms  of  another  expression  E.  We  can 
remove  the  need  for  E  by  making  sure  that  R  is  maintained  throughout  the  program.  That  is, 
wherever  the  value  of  E  changes,  we  introduce  code  to  incrementally  update  R. 

. Examples  of  Use . 

Router  References :  1.8, 1.11, 1.18,  3.4,  5.2 

Example  A 

Router  Reference :  1.11 

Development  context:  The  goal  of  step  1.10  is  to  map  the  derived-relation 
PACKAGES_EVER_AT_SOURCE  (or  PEAS).  There  are  several  general  strategies  we  wean 
try:  maintain  the  relation  incrementalyy;  unfold  the  relation  where  ever  it  is  used  (lazy 
evaluation).  The  relation  PEAS  is  ideally  suited  for  an  incremental  maintenance  approach: 
packages  are  added  to  the  end  of  the  sequence  one  at  a  time. 


relation  PACKAGES  EVER  AT  SOURCE /package  seolseouence  gl  package) 
d*£lntLtQa  package.seq  • 

({ package  ||  (package : located.at  ■  source)  asof  everbefore) 
ordered  tempo  rail  v  bv  start  (package:  located,  at  «  idft  source)); 

The  Maintainlncrementally  goal  posted  at  1.11  triggers  several  competing  methods.  That  is, 
the  concept  or  general  strategy  of  incremental  maintenance  was  generalized  into  a  goal  with 
a  set  of  methods  or  tactics  for  actually  carrying  it  out.  The  method  we  will  use  introduces  a 
demon  which  "watches"  for  relevant  changes  (a  package  becoming  located  at  the  source 
station)  and  does  the  necessary  update  to  PEAS. 
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daman  NOTICE.NEW.PACK AGE_AT_SOURCE(pac*age.new ) 
trigger  package. new: located. at  ■  the  source 
response 

update  package  jseq  in  PACKAGES_EVER_AT_SOURCE(S) 

Hi  PACKAGES_EVER_AT_SOURCE  concat  <package.new>: 

relation  PACKAGES  EVER  AT  SOURCE  (package  seal  sequence  fil  package); 


Example  B 

Router  Reference :  1.8 


In  step  1 .8  we  wish  to  incrementally  maintain  the  relation  PREVIOUS.PACK  AGE: 


relation  PREVIOUS_PACKAGE(prev_pac*age  |  package) 
definition  prev_package  • 

(A  package.previous  1 1 

package. previous  immediately  <  lastf  PACKAGES  EVER  AT_SOURCE(* ) ) 
wrt  PACK  AGES  JEVER_AT_SOURCE(  • ) ) ; 


Instead  of  using  a  demon  as  in  example  A,  we  will  employ  a  method  which  scatters 
maintenance  code  (>2)  at  every  location  within  the  program  where  the  relation  may  change, 
i.e.  where  its  base  relation  PACKAGES_EVER_AT_SOURCE  changes.  There  is  only  one 
such  location  (►1)  and  that  is  found  within  NOTICE_NEW_PACK  AGE_AT_SOURCE. 
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relation  PREVIOUS_PACKAGE(prev_paeftaga  |  package); 

demon  NOTICE.NEW.P  AC K AGE.AT.SOU HCE(package.new ) 
triooer  oackaae.new: located  at  *  Ull  source 
response 
atomic 

►j  update  package_seq  in  PACKAGES_EVER_AT_SOURCE($) 

in  PACKAGES_EVER_AT_SOURCE  concat  <package.new> ; 

►2  update  prevjackage  in  PREVIOUS.PACKAGE(S) 

to  ( the  package. previous  1 1 

package. previous  immediate! v  before 

lftii(PACKAGES_EVER_AT_SOURCE(*)  concat  <package.new>) 
mrt  PACKAGES_EVER_AT_SOURCE(*)  concat  (package. new>) 


£M  atomic 
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E.10.  Purify 

Purify(A|acf/on) 

Achievement  Condition:  A  does  not  appear  inside  an  uncontrollable  portion  of  the 
spec. 

Goal  Description:  During  a  development,  the  unfolding  and  maintaining  of  defined 
structures  may  lead  to  the  introduction  of  code  into  portions  of  the  specification  which  are 
uncontrolable.  For  instance,  a  specification  may  contain  a  model  of  the  environmentin  which 
the  application  program  is  to  run.  Code  introduced  intosuch  uncontrollable  portions  must  be 
moved  to  parts  of  the  spec  that  are  under  control  of  the  application  program.  We  Purify  a 
newly  introduced  action  A  by  either  1)  doing  nothing  if  A  is  in  the  implementable  portion  of  the 
spec  (the  goal  is  trivially  satisfied)  or  2)  removing  A  from  the  uncontrollable  portion. 

. Examples  of  Use . 


Router  reference :  5.10, 5.14 

Example  A 

Router  Reference :  6.10 

Development  context:  in  the  process  of  maintaining  PACK  AGES_DUE_AT_S  WITCH  in 
section  5  maintenance  code  (►,)  is  introduced  into  the  demon  CREATE.PACKAGE: 
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daman  CREATE_PACKAGE( ) 
trifloer  RANDOM () 
response 
atomic 

create  package. new  \  j 

package. new : destination  *  a  bin  and 
package. new :  located_at  «  the  source ; 

►j  loon  ( switch  1 1 

MEMO_LOCATION.BIN (switch ,  package. new :  destination)  ) 
do  update  packages_due  sd.  PACKAGES_DUE_AT_SWITCH(5w/fch,$) 
ill  PACKAGES_DUE_AT_SWITCH(sw/fch,*)  concat  <package.new> 
AM  atomic: 


In  step  5.10,  we  post  a  goal  to  Purify  the  new  code.  Since  CREATE.PACKAGE  is  outside  the 
implementable  portion  of  the  spec  ••  it  is  a  part  of  the  model  of  the  environment  -  the 
achievement  of  the  goal  rests  on  moving  the  code  to  an  implementable  part  of  the  spec,  in  this 
case  the  demon  RELEASE_PACKAGE_INTO_NETWORK. 
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E.1 1 .  Reformulate 

Reformulate(C|consfrucf,  P\pattern) 

Achievement  Condition:  A  state  is  reached  where  C  matches  P 

Goal  Description:  Using  the  Reformulation  goal,  the  user  can  describe  a  goal  state  as  a 
syntactic  pattern.  Such  a  general  goal  has  great  expressive  power.  In  fact,  we  can  express 
several  other  defined  goals  through  the  Reformulate  goal:  Remove  given  the  empty  state  as  a 
pattern;  sometimes  Map  where  the  mapped  state  can  be  described  by  a  syntactic  pattern  (e.g. 
derived-relations). 

Over  reliance  on  syntactic  goal  descriptions  loses  the  development  abstraction  we  strive  for, 
i.e.  an  explicit  vocabulary  of  goals  for  which  specific  methods  can  be  developed.  Currently, 
use  of  the  Reformulate  goal  in  a  development  is  viewed  as  ad  hoc:  the  pattern  has  not 
occurred  enough  to  generalize  into  a  new  goal  descriptor.  As  more  experience  is  gained  in 
developing  programs  using  Glitter,  we  expect  further  pattern  generalization  to  occur. 

. —  Examples  of  Use . 

Router  References:  1.5,  1.13, 1.14, 1.16, 1.20,  2.12,4.6,  6.9, 6.11 

Example  A 

Router  Reference :  1.5 

Development  context:  Before  a  derived  object  is  folded  into  a  derived  relation  (i.e.  Isolated ), 
an  attempt  is  made  to  remove  as  much  linkage  to  the  local  context  as  possible  (i.e.  Globalize). 
In  step  1.5,  the  local  variable  package. new  is  to  be  reformulated  into  a  global-expression , 
one  which  consists  solely  of  relations  and  global  objects.  At  step  1.6,  this  goal  has  been 
further  reduced  to  reformulating  the  variable  into  an  expression  on 
PACKAGES<-EVER«-AT«-SOURCE,  namely  lastfPACKAGES  EVER  AT  SOURCEflV 
Having  gotten  this  far,  the  system  does  not  have  the  necessary  theorem  proving  capability  to 
show  that  these  two  expressions  are  equivalnet,  and  hence  relies  on  the  user  to  fill-in  the  last 
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Example  B 

Router  Reference :  1.13,  1.14 

Development  context:  The  goal  of  step  1.12  is  to  remove  the  reference  to 
PACK  AGES_EVER_AT_SOURCE  from  the  following  context: 


►  j  (the  package. previous  \  \ 

package.previous  immediate! v  before 

last( PACKAGES_EVER_AT_SOURCE(*)  concat  <package.new> ) 
v»r t  PACKAGES_EVER_AT_SOURCE(*)  concat  <package.ne w>) 


The  method  chosen  attempts  to  reformulate  the  derived  object  ►  as  a  positional -retrieval  on 
PACKAGES_EVER_AT_SOURCE  which  may  prove  easier  to  work  with: 

goal -pattern:  la$i(S| sequence) 

A  method  exists  for  reformulating  derived  objects  of  a  certain  type,  namely  ones  that  do  a 
trivial  binding: 

goal  pattern:  (x  ||  x  «  lA£i(S| sequence)) 

Finally,  a  method  exists  for  reformulating  relative  retrievals  from  a  sequence  into  positional 
ones: 

goal  pattern:  x  immediately  before  y  (S\ sequence  concat  z) 

This  last  pattern  can  be  matched  directly  against  the  current  state. 

Example  C 

Router  Reference'.  4.6,  6.9 

Development  context:  A  general  means  of  making  two  expressions  equivalent  is  to  hold 
one  steady  and  reformulate  the  other.  This  crops  up  several  places  within  the  router 
development  when  two  demon  triggers  need  to  be  made  equivalent.  In  the  first,  RANDOM 
must  be  reformulated  as 
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package  «  first  (PACKAGES  DUE  AT  SWITCHf.  switch) 
and 

SWITCH  JS.EMPTY  (switch  ) 

Here,  a  method  which  replaces  a  random  event  with  a  more  specific  event  is  chosen. 

In  the  second,  we  must  reformulate  the  relation  reference  SWITCH  JS.EMPTY  ( switch )  as 
package :  located_at  >  switch 

Here,  a  method  which  unfolds  the  relation  at  its  reference  point  is  chosen. 
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E.12.  Remove 

Remove(  S|  construct,  C|  construct) ) 

Achievement  Condition:  Structure  S  is  removed  from  context  C 

Goal  Description:  The  removal  of  structure  S  from  context  C  may  be  motivated  by  any  of  the 
following: 

1 .  S  is  deadwood;  no  use  is  made  of  S  within  C. 

2.  S  is  a  component  of  some  larger  structure  X;  by  stripping  away  all  components  of 
X,  X  can  be  removed  (see  1  above). 

3.  C  is  a  portion  of  the  specification  outside  of  which  we  have  control. 

. Examples  of  Use . 

Router  References:  1.1, 1.2, 1.12, 1.10, 1.21,2.1,2.2, 3.1, 3.2,  3.5,  5.11,5.15 

Example  A 

Router  Reference :  1.1 

Development  context:  section  1  of  the  router  development  centers  on  optimizing  the 
relation  (sequence)  PACKAGES_EVER_AT_SOURCE.  In  particular,  we  only  reference  the 
last  element  of  this  sequence  and  hence,  have  no  need  for  the  entire  history  of  packages  ever 
entering  the  router.  In  step  1 .1 ,  the  user  states  his  desire  to  Remove  this  relation71 . 

relation  PACKAGES_EVER_AT_SOURCE(pac*ape_seq  |  sequence  g£  package) 
definition  package jseq  • 

({ package  ||  ( package : located_at  «  source)  asof  everbeforel 
ordered  temporally  fcy  start  (package: located. at  ■  the  source)): 

After  a  number  of  development  steps,  the  above  relation  is  removed  from  the  spec,  and  as 
residue,  the  following  two  relations  are  left: 

71  Note  the  difference  between  mapping  the  relation  and  removing  the  relation.  A  mapping  goal  would  be 
achieved  when  we  had  eliminated  the  derivation  freedom  from  PACKAGES_EVER_AT_SOURCE  (aee  atep  1.9).  the 
remove  goal  when  the  entire  relation  has  been  eliminated.  In  fact,  the  remove  goal  is  a  more  specific  case  of  the  map 
goal:  removing  a  derived  relation  entirely  is  one  way  of  getting  rid  of  the  freedom. 


E.12  Remove 


PAGE  391 


relation  PREVIOUS  PACK AGE( prey  package  |  package); 
relation  LAST_PACKAGE(/asf_pacfcage  |  package); 

Example  B 

Router  Reference:  Text  Preprocessor 

Development  context:  in  much  the  same  way  that  the  sequence 
PACKAGES_EVER_AT_SOURCE  was  unused  in  example  A  above,  an  action  may  be 
"unused".  That  is,  there  may  be  no  references  to  its  effects.  In  the  text  preprocessor 
development,  we  reach  the  following  state  (see  example  B,  section  E.2): 


begin 

if  predecessor(space  Char  Text) 
then  begin 

►  .  invoke  REPLACE  (Char newepace  Text)', 

invoke  REMOVE(  Char  Text) 

end 

else  invoke  REPLACE ( Char  newspace  Text ) ; 
end 


The  first  replace  procedure  ►1  is  wasted  effort  since  the  next  action  is  to  REMOVE  the 
character.  A  goal  is  posted  to  Remove  the  call  on  REPLACE 

Example  C 

Router  Reference :  5 . 1 1 

Development  context:  the  above  examples  have  dealt  with  removing  a  construct 
completely,  i.e.  from  the  entire  spec.  The  Remove  goal  can  also  be  used  to  remove  a 
construct  from  a  more  specific  context.  For  example,  the  effect  of  maintaining  a  derived 
relation  is  to  place  maintenance  code  anywhere  in  the  spec  where  the  relation  might  change. 
Some  of  these  locations  may  be  outside  of  the  portion  of  the  spec  over  which  we  have  direct 
control,  e.g.  the  portion  of  the  spec  that  models  the  environment.  Such  is  the  case  in  the 
maintenance  of  PACK  AGES_DUE_AT_S  WITCH  in  section  5.  Code  is  introduced  into  the 
demon  CREATE_PACK  AGE,  part  of  the  model  of  the  router  environment: 


.s  s 


HA't  It  i 
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H  CREATE_PACKAGE() 
trinoar  RANDOM () 

rflliLQ.QA.ft 

atomic 

create  package. new  1 1 

package. new :  destination  ■  ft  bin  and 
package. new : located. at  ■  tha  source ; 
loop  (switch  1 1 

MEMO_LOCATION_BIN(sw/fc/7 ,  package. new : destination ) ) 
do  update  packages  jiue  ft£  PACK  AGES.DUE.AT.S  WITCH  (switch, S) 
1ft  P  AC  K  AGES.DUE.AT.S WITCH  (switch,9)  concat  <package.new> 
M4  atomic: 


The  maintenance  code  ►1  must  be  removed  from  CREATE.PACKAGE.  While  we  could 
attempt  to  remove  it  from  the  entire  spec,  reasoning  that  this  is  one  way  of  removing  it  here 
(this  method  is  used  in  removing  the  same  maintenance  code  from 
RELEASE.PACKAGE.INTO.NETWORK  in  section  5)  the  actual  method  chosen  attempts  to 
move  the  code  out  of  CREATE.PACKAGE  (and  into  the  implementable  portion),  hence 
satisfying  the  goal. 


E.1 2  Remove 
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E.1 3.  Show 


ShO  W  (  P\proparty ) 

Achievement  Condition:  P  asserted 

Goal  Description:  The  validity  of  many  development  methods  rest  on  showing  that  certain 
properties  hold  in  the  current  state  of  the  program.  Sometimes,  one  or  more  of  the  arguments 
to  a  property  may  be  unbound.  In  these  cases  the  task  is  to  find  some  binding  that  makes  the 
property  hold.  Below  are  listed  the  currently  defined  set  of  properties.  Following  each 
property  is  the  locations  in  the  router  development  where  it  is  used  as  an  applicability 
condition  for  a  chosen  method. 

ACTION JS_UNNOTICEb(A|aCf/on)  (1 .22, 3.5) 

An  action  A  is  unnoticed  if  either  it  has  no  effects  or  its  effects  are  not 
used  by  any  subsequent  computation. 

COMPUTATIONAL!.  Y_BETWEEN(E|express/on,  A1  fact  ton,  A2|ecf/on)  (2.5) 

The  expression  E  is  computed  after  At  is  executed  but  before  A2  is 
executed. 

EVENT_BEFORE_EVENT (B) BVOHt,  E|evertf)  (4.14) 

Event  B  occurs  before  event  E. 

FiNiTE.EXPLiCATiON(DR|der/ved  flat  ion)  (5.4) 

A  finite  number  of  explicit  data  base  assertions  will  compute  DR. 

FUTURE.EVENT(F|evenf,  C|evenf)  (4.11) 

Event  F  occurs  after  event  C. 

GENERALIZABLE_TRIGGER(T|/r/gger)  (6.1 1) 

The  trigger  (-3  x  II  P(x))  can  be  replaced  by  ~P(x). 
iMPUED_BY(Q|express/on,  P\exprasslon)  (4.1 , 4.9, 4.12) 

Logical  implication:  P  ■  >  0. 

iNDiviDUAL_START(D|demon)  (6.2, 6.14) 

If  D  has  a  conjunctive  trigger,  none  of  the  arms  ever  occur  simultaneously. 

introouceable_var_name(V| var/ab/e-name,  D\declarativa-construct)  (2.12, 6.19) 

It  is  legal  to  introduce  V  as  a  variable  declared  in  D,  i.e.  V  does  not  conflict 
with  any  existing  variables  declared  by  D. 


LAST_ACTiON(A|acf/on,  E|acf/on-evenf)  (4.15) 
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E  specifies  the  event  of  an  action.  Action  A  is  the  location  of  the  last  such 
event  relative  to  current  location. 

mergable„DEMONS(B1  [demon-body,  B2\demon-body,  l| ordering)  (2.9, 4.4, 6.7, 6.16) 

The  value  of  I  is  an  interleaving  of  the  two  demon  bodies  B1  ,B2  suchthat 
valid  behaviors  remain. 

NON.EMPTY.SPECIALIZATION(S|expreSS/on)  (4.6) 

E  does  not  rule  out  all  behaviors. 

SEOUENTiAL_ORDERiNG(0|orcto/7ng,  X|afom/c)  (2.7,5.13,  5.16) 

The  statements  of  X  have  been  ordered  in  O.  The  ordering  is  a  valid 
sequentiation  of  the  parallel  atomic. 

SUPERPLUOUS.ATOMIC(A|afOm/C)  (2.7, 5.13, 5.16) 

The  statements  in  A  do  not  need  to  be  executed  as  a  single  step,  i.e.  no 
other  construct  (demon, constraint)  gains  or  loses  triggerings. 

SWAPPABLE(Al|action,  A2|action)  (2.14) 

Ai  does  not  modify  any  data  referenced  by  A2.  A 2  does  not  modify  any 
data  referenced  by  AI . 

UNCHANGED_BETWEEN_EVENTS(P|express/on,  El  (event,  E2|evenf)  (2.5, 4.17) 

The  value  of  P  does  not  change  between  the  two  events  El  ,E2. 

UPDATE_vALUE_HOLDS(U|wpdafe,  R|re/aMon-reference)  (2.4) 

Given  that  U  modifies  the  value  of  X  to  V,  this  modification  is  unchanged 
(X's  value  is  still  Y)  when  R  is  computed. 

value_known(R| relation-reference,  V| object)  (2.3) 

The  value  of  R  is  V. 


Examples  of  Use 


In  some  cases,  methods  exist  for  asserting  needed  properties,  and  in  some  cases  the 
necessary  reasoning  is  beyond  the  reach  of  the  system  and  the  user  is  called  to  verify  and 
assert  the  property.  The  examples  below  show  both  types  of  processes. 

Example  A 

Router  Reference :  1.22 

Development  context:  at  step  1-1,  a  goal  is  posted  to  remove  the  relation 


E.13  Show 
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PACK  AGES«-EVER«-ATvSOURCE.  The  method  chosen  attempts  to  remove  ail  reference  to 
the  relation.  At  step  1.21,  a  subgoal  is  posted  to  remove  one  such  reference,  an  update  of  the 
relation. 

update  package_seq  in  PACKAGES_EVER_AT_SOURCE($) 
to  PACKAGES_EVER_AT_SOURCE  concat  <package>) 

The  method  chosen  to  remove  the  update  relies  on  showing  that  the  update  is  unnoticed,  i.e. 
no  other  subsequent  expression  references  the  new  value.  At  step  1 .22,  a  Show  goal  is  posted 
to  show  that  the  update  is  inedeed  unnoticed.  The  method  chosen  to  assert  the  necessary 
property  is  ShowDysteleological.  This  method  takes  a  rather  unsophisticated  approach, 
asserting  the  property  when  references  exist  to  the  updated  relation,  not  just  ones  effected 
by  the  update. 

Example  B 

Router  Reference :  2.3 

Development  context:  as  in  the  previous  example,  at  step  2.2  a  reference  to  a  particular 
relation,  PREVIOUS.PACKAGE,  is  trying  to  be  removed  so  that  the  relation  itself  can 
eventually  be  removed. 

it  PREVIOUS_PACKAGE(  • ) :  DESTINATION  *  package. new :  destination 
then  invoke  WAIT[]; 

•  •  • 

relation  PREVIOUS  PACKAGEforev  package  |  package); 

The  method  chosen  attempts  to  rpelace  the  reference  with  an  actual  value.  To  do  this,  the 
method  posts  a  goal  at  step  2.3  to  show  that  the  value  is  known  at  the  point  of  reference.  The 
method  chosen  to  assert  the  property  relies  on  showing  still  another  property:  an  update  U  of 
the  relation  to  value  V  still  holds  at  the  reference.  Showing,  in  general,  that  V  is  the  relation's 
value  at  the  reference  is  beyond  the  reasoning  power  of  the  system;  the  user  is  called  on  to 
assert  the  necessary  property.  Note  that  while  the  system  was  required  to  call  on  the  user  for 
assistance,  the  chosen  method  did  a  portion  of  the  reasoning  necessary  to  set  a  more  specific 
context  for  the  user. 
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E.14.  Simplify 

Simplif  y(  C|  construct ) 

Achievement  Condition:  No  simplification  transformation  firings 

Goal  Description:  The  posting  of  this  goal  causes  the  transformations  in  the  simplification 
subcatalog  (see  F.16)  to  be  run  until  a  quiescent  state  is  reached,  i.e.  none  of  the 
transformations  fire.  C  bounds  the  context  in  which  simplification  is  to  be  carried  out. 
Chapter  5  discusses  simplification  isuues  in  more  detail. 

. Examples  of  Use . 


In  the  router  development  of  appendix  B,  we  have  omitted  the  explicit  posting  of  simplification 
steps  in  favor  of  textual  comments. 

Example  A 

Router  Reference:  4.19,  after  unfold 

Development  context:  as  happens  in  the  development  as  a  whole,  simplification  often 
requires  a  joint  effort  between  user  and  machine.  The  simplification  of  many  constructs  relies 
on  the  user  to  provide  sophisticated  reasoning  to  prime  the  process.  The  simplification  at  step 
4.19  is  one  such  example.  We  are  given  the  following  state: 


S3 


Vji'A-V.'V 
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% 
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demon  SET_SWITCH(sm'fcft .  package ) 

triooer  package  *  f  i  rst(  PACKAGES  DUE  AT  SWITCH  (  *  .switch) ) 
and 

SWITCH  JS.EM  PTY  { switch ) 

response 

update  : SWITCH.SETTING  fli  switch  la 

( pipe  ||  pipe  •  switch :  switch_outlet 
and 

SWITCH  JS.EMPTY  ( switch ) 
and 

►  j  ~(  LOCATION_ON_ROUTE_TO_BIN(sw/fch  . 

package :  destination  ) 
and 

-LOCATION_ON_ROUTE.TO.BIN [pipe , 

package :  destination  ) ) ; 


The  user  can  reason  that  switch  is  indeed  on  the  route  to  package's  destination  (first  term  of 
►.,)  and  so  can  get  rid  of  this  term.  However,  the  system  currently  has  no  indirect  reasoning 
machinery,  and  hence  cannot  show  that  the  definition  of  PACKAGES_DUE_AT_SWITCH 
requires  that  switch  be  on  the  route  to  package's  destination.  The  user  is  required  to  get  the 
process  going: 


STEP  4.20(user):  Manual 

MANUAL.REPLACE  LOCATION_ON_ROUTE_TO_BIN(sw/fch ,  package : destination) 
with 
true 


STEP  4.21  (user):  Simplify  ^ 

The  resulting  simplification  process  takes  the  following  form: 


Applying 

( . . .  true  md  term) 


( . . .  term ) 


. .  .~(-LOCATION_ON_ROUTE_TO^BIN(p/pe,  package:  destination)  ) ; 


Applying 

-(term) 


- term 
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gives 

.  .  . — LOCATION_ON_ROUTE_TO.BIN  ( pipe,  package: DESTINATION) ; 
Applying 

— term  *♦  term 
gives 


demon  SET.SWITCH (switch ,  package) 

trigger  package  •  f  irstf  PACKAGES  DUE  AT  S WITCH (•. switch)) 
and 

SWITCH  JS.EMPTY  ( switch ) 

response 

update  :  SWITCH.SETTING  flf  switch  ig 
►  ,  ( pipe  |  |  pipe  *  switch :  SWITCH.OUTLET 

and 

►2  SWITCH  JS.EMPTY  (switch) 

and 

LOCATION_ON.ROUTE_TO.BIN  (p/pe . 

package :  destination  ) ) ; 


The  same  process  can  be  carried  out  in  removing  the  second  conjuct  arm  >3:  replace  it  with 
true  (again  the  user  must  provide  the  reasoning)  and  simplify  the  conjunction  This  givos 
us 


demon  SET.SWITCH ( switch ,  package) 

trigger  package  «  £i££i( PACK AGES_DUE_AT_SWITCH (•  .switch) ) 
and 

SWITCH  JS.EMPTY  ( switch ) 

response 

update  :  SWITCH.SETTING  fil  switch  ig 
►3  (pipe  ||  pipe  *  switch :  switch.outlet 

and 

LOC  ATI  ON.ON.RO  UTE.TO.BI  N  ( pipe , 

package :  destination  ) ) ; 


E.  14  Simplify 
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E.15.  Swap 

Swap(  Aljacf ion,  A2|acf/on ) 

Achievement  Condition:  A1  and  A 2,  brothers  in  a  begin/end  block,  are  interchanged 
Goal  Description:  allows  the  exchange  of  one  or  more  actions  within  a  begin/end  block. 

. Examples  of  Use . 

Router  references:  2.14 

Example  A 

Router  Reference :  2.14 

Development  context:  our  goal  in  step  2.13  is  the  computation  of  the  update  to 
LAST.PACKAGE  (►,)  after  the  reference  to  PREVIOUS.PACKAGE  (►j). 


demon  RELE A SE.P A C K AGE J NTO.NETWOR K  ( package. new ) 
trigger  package. new : located. AT  ■  ihg  source 

neifiao.&fi 

begin 

update  prevj>ackage  jjQ.  PREVIOUS  PACKAGE(S) 

Ifi  LAST_PACKAGE(*) ; 

►i  update  tastjiackage  in  LAST_PACKAGE(S) 
to  package. new 

►  .  If.  PREVIOUS_PACKAGE(») :  destination  *  package. new.  destination 
then  WAIT[] ; 

update  :located_at  gf  package. new  lg  (ihg  source) :  SOURCE.outlet 

find; 


The  method  chosen  attempts  to  Swap  the  two  statements. 
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E.1 6.  Unfold 

Unfold(  D| definition,  preference ) 

Achievement  Condition:  D  unfolded  at  reference  point  R 

Goal  Description:  Given  that  our  specification  language  gives  us  the  ability  to  create  global 
parameterized  definitions  (e.g.  procedures,  derived -relations,  constraints,  demons)  and  local 
implicit  and  explicit  references  to  them,  we  would  sometimes  like  to  replace  the  local 
reference  with  the  instantiated  definition.  The  motivation  for  this  step  can  be  one  of 
optimization  (calls  may  be  expensive),  mapping  (mapping  a  derived  relation  by  unfolding  it 
everywhere  it  is  referenced,  a  demon  everywhere  it  is  triggered)  or  catalytic  (the  introduction 
of  the  definition  in  the  local  context  allows  further  optimizations  to  occur).  The  Unfold  goal 
requests  that  a  particular  global  definition  be  instantiated  at  a  particular  reference  point. 


Examples  of  Use 


Router  References :  2.7,  5.6, 5.9,  5.13,  5.17,  6.4, 6.10,  6.21 

Example  A 

Router  Reference :  6.10 

Development  context:  One  means  of  reformulating  a  derived  relation  is  to  unfold  it 
wherever  referenced.  Given  the  definition  and  use  of  SWITCH_IS_EMPTY  below 


relation  SWITCH JS_EMPTY ( switch ) 

definition  -3  package  1 1  package : located.at  *  switch ; 

trigger  SWITCH  JS.EMPTY (switch) 


we  can  unfold  SWITCHJS.EMPTY  to  get 


>.V>.  VAU  v.v_\  121  ,  IK:* 
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trigger  -3  package  ||  package : located.at  «  switch; 


From  this  point,  one  more  reformulation  leads  to  the  desired  state. 

Example  B 

Router  Reference :  6.4 

Development  context:  We  can  view  the  reference  of  a. demon  as  a  location  that  causes  a 
state  change  which  may  cause  the  demon  to  trigger.  Step  6.4  requests  that  the  demon 
SET_SWITCH_WHEN_BUBBLE_PACKAGE  be  unfolded  at  such  a  location 


demon  SET_SWITCH_WHEN_BUBBLE_PACKAGE(sw/fch) 
trigger  3  package  \ \ 

package  «  fi rstf PACKAGES  DUE  AT  SWITCHf  switch)) 
response. . . ; 


►  j  update  packagesjdue  PACK  AGES_DUE_AT_S WITCH  ( switch ,  S ) 

to  PACKAGES_DUE_AT_SWITCH(sw/fch ,  • )  concat  <package.new> ; 


F  Method  Catalog 
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Appendix  F 
Method  Catalog 


F.1 .  Catalog  Notation 

The  presentation  of  the  Glitter  development  methods  will  be  grouped  around  the  individual 
Gold  descriptors.  Each  method  will  be  presented  using  the  following  format: 

Method  <name> 

Goal:  [{triggering  goal)]1 
Filter :  [(boolean  expression>]° 

Action:  [{development  actions)]1 
[  Short  description  of  method.  ] 

References :  list  of  triggering  steps  for  this  method 
End  Method 


A  method’s  <name)  is  used  to  give  it  a  unique  textual  handle  and  is  intended  to  give  a  short 
description  as  well. 


i 


✓ 


V. 

V 


£ 


The  references  list  points  into  the  router  development  in  appendix  C.  The  items  of  this  list  are 
steps  where  the  method  was  competing.  Steps  listed  in  boldface  are  ones  where  the  method 
was  chosen. 

The  rest  of  the  fields  conform  to  the  description  given  in  chapter  6. 
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|  Method  Pastlnductlon 

Goal:  easily  C|  +  constraint 

Action:  1)  Reformulate  C  as  + constraint  P  during  E 

2)  Show  EVENT_BEFO«E_EVENT ( B ,  E) 

3)  Apply  pastjnoucton_casify(C,  B) 

[Use  induction  Irom  some  past  state.] 

References:  4.8,  4.11,  4.14 
|  End  Method 


I 


I 


|  Method  CasIfyFromUntllEverConstralnt 


Goal  :  Casily  C  \  *  constraint 
Action:  1)  Relorumlate  C  as 

P  from  E  until  evermore 
2)  Apply  CASIFY_AS_NOW_AND.AFTEn(C) 

[ You  can  show  that  C  holds  Irom  E  until  ever  after  It  you  can  show  It  holds  at  E  and  afte  E.] 
References:  4.8.  4.11,  4.14 
|  End  Method 


|  Method  CasIfyAroundEvent 

Goal:  Casily  C|eo nstraint 

Action:  1)  Reformulate  C  as  constraint  P  after  E 

2)  Show  FUTUBE.EVENT  ( F ,  E) 

3)  Apply  CASIFY_ABOUND_EVENT(  C  ,  F) 

[Choose  some  event  F  in  the  future  and  show  that  C  holds  before,  during  and  alter  F.] 
References:  4.8,  4.11,  4.14 
|  End  Method 


I 


M 

7. 


|  Method  MoveOutOf Atomic 

Goal:  ComputaSaquantiaily  B | action  before  A|#ct/on 
Pillar:  a)  co»ponent-of [A,  C | atomic) 

Action:  1)  Untold  C 

[It  you  ara  trying  to  mova  A  attar  B  and  A  Is  In  an  atomic,  unfold  tha  atomic  batora  attempting  to 
continua.) 

Reference*:  2.6 
|  End  Method 


I 


F.3  ComputeSequentially 
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|  Method  SwapUp 


Goal :  ComputeSequentielly  Y  before  X 
Filter:  a)  brother-of[X,  Y] 

Action:  1)  Swap  Y  with  predecessor  of  Y 

[II  you  are  trying  to  computa  X  altar  Y  than  move  Y  up.] 
References:  2.13 
|  End  Method 


I 


F.4.  Consolidate 


|  Method  MergeDemons  | 

Goal:  Consolidate  01 1 demon  and  02 1 demon 
Action:  1)  Equivalence  t rlgger-of(Ol)  and 

tr1gger-of[D2J 

2)  Equivalence  var-declaratlon-of [Dl]  and 

var*dec1arat1on*of[D2] 

3)  Show  meagablE_DEmons(01  .  02,  1 1  ordering) 

4)  Apply  oeMON.MEBOE{Dl .  02,  1) 

[You  can  consolidate  two  demons  H  you  can  show  that  they  have  the  same  local  variables,  the 
same  triggering  pattern  and  that  they  meet  certain  merging  conditions.] 

References :  2.9,4.4,8.7,6.16 

|  End  Method  | 
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|  Method  Consol IdateEnumeratlonLoops  | 

Goa/:  Consolidate  L 1 1 action  and  L2|ecf/on 
Action:  1)  Reformulate  LI  as  enumeration-loop 

2)  Reformulate  L2  as  enumeration-loop 

3)  Equivalence  generator-of[*,  111  *hd 

generator-off* .  L2] 

5)  Show  MCBO ABLE. L OOPS (  LI ,  12) 

6)  Apply  MERGE. ENOMERATON_IOORS(  LI ,  L2  ) 

(To  consolidate  two  loops,  make  tnair  generators  equivalent  end  show  that  they  ere  mergabie.) 
References:  TextPreprocessor 

|  End  Method  | 


|  Method  Consol IdateSimpleCondsl  | 

Goal:  Conaolidate  Cl|1f  P  than  A  and 
C2I.H  0  than  B 

Action:  1)  Equivalence  P  and  Q 

2)  Show  (hoaro-axlom)  P  {A}  Q 

3)  Apply  MenGE_8)MRLE_cONDS.wrrM_s*Me.PREDiCATE( Cl .  C2) 

(it  P  then  a-.ii  P  then  b  **  HP  then  a:b  under  certain  conditions .} 

References:  unused 

|  End  Method  I 


|  Method  Consol 1dateS1mpleConds2  I 

Goal:  Conaolidate  Cl|l£  P  than  A  and 
C2|H  0  than  B 

Action:  l)  Equivalence  A  and  6 

2)  Show  (hoaro-axlom)  P  {A}  -0 

3)  APPlv  MeBOe.WMPLE.CONt)8.wrTM.SAME.XCTION(Cl,  C2) 

(H  P  then  e,H  0  then  a  »  HP  or  0  then  a  under  certain  conditions .) 

References:  TextPreproeossor 

|  End  Method  I 


iv\  i.t  <.v.\  ;va  ’.-. 
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F.5  Equivalence 


F.5.  Equivalence 


|  Method  EquivalancaCompoundStructurasl 


Goal:  Equivalence  SI  \  compound-structure  and 
S2 1  compound-structure 

Filler:  a)  glst-typa-of]*.  SI]  •  g1*t-type-of[V  S2] 
b)  f  1xed-*tructure{Sl] 

Action:  1)  forall  pa1r*1*e-coniponent-oflCl.C2,Sl.S2] 
fla  Equivalence  Cl  and  C2 


{Divide-and -conquer:  make  the  components  o I  two  fixed  structures  equivalent.} 
References :  unusad 
End  Method 


|  Method  Equ1valenceCo<npoundStructures2 


Goal:  Equivalence  Si  |  compound-structure  and 
S2 1  compound-structure 

Fitter-,  a)  glat-typa-of ]• ,  SI]  *  glst-type-of]*,  S2] 

b)  -f1xed-*tructure(Sl] 

c)  compon#nt-correspondence[Sl ,  S2,  C  |  correspondence] 

Action :  1  )  fpran  correspondance*pa1rt[C,  Cl,  C2] 

do  Equivalence  Cl  and  C2 


{ Divide-and-conquer ;  make  the  components  of  two  non-fixed  structures  equivalent.} 
References  :  2.10,6.17 
End  Method 


|  Method  Anchorl 


Goal:  Equivalence  X  and  Y 
Action:  1)  Reformulate  Y  as  X 


l Try  changing  the  second  construct  into  something  that  matches  the  first.} 
References:  1.16,  2.10,  2.11,  4.6,  6.6,  6.12,  6.18 
End  Method 
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|  Method  Anchor2 


Goa/:  Equivalence  X  and  Y 
Action:  1)  Rotor  mulct*  X  as  Y 


/Try  changing  tha  first  construct  into  something  that  matches  the  second.] 
References:  1.15,  2.10,  2.11,4.5,  6.5.  6.12.  6.16 
|  End  Method 


|  Method  AddNewVar 


Goal:  Equivalence  Ll  |  variable-list  and  L2 1  variable-list 
Filter:  a)  1ength[Ll]  >  1ength[L2] 

b)  membe r[V |  variable-declaration .  Ll] 

c)  -mamba  r]V.  L2] 

Action :  1)  Show  MTOODUCABLE>VAa»NAME(V.  L2) 

2)  Apply  wthoooce-new«va«{V.  L2) 


fT ry  adding  a  new  var  to  make  the  two  lists  equfvalenet  J 
References:  6.19 
|  End  Method 


F.6.  Factor 


|  Method  FactorDBMalntenancelntoAction 


Goal:  Factor  U| db-meintenance  In  L 

Action:  1)  Apply  c»Eate_action_from_template ( U  A) 

2)  forall  mstch-pattarnlu,  W,  L) 
dO  Apply  *EW.ACE_DBMAINTENACE_wrrH_ACTION(W  A) 


{ Create  a  new  action  A  and  then  find  all  matches  W  In  L  and  replace  each  with  a  call  to  the  new 
action  A.] 

References:  6.5 
|  End  Method 
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|  Method  Flatten 


Goa/:  Flatten  OR | derived-relation 
Action:  1)  forall 

reference-local  ion[BR  |  derived-relation  ,0H] 
do  Map  BR 

(Map  all  derived  ralations  found  In  DR  Into  simple  ones.] 
References :  1 .9,  5.3, 5.7 
|  End  Method 


F.8.  Globalize 


|  Method  Global IzeActlon 


Goal:  Globalize  A  |  action 

Filter:  a)  component-of[A,  X | atomic] 

Action:  1)  Unfold  X 

[You  cant  pull  something  out  of  an  atomic:  jitter.] 
References:  5.12,5.16 
|  End  Method 


I 


|  Method  Global IzeDerlvedObject 

Goal:  Globalize  DO  |  derived-object 
Action:  l)  forall  loeatlon-refarancetv,  $,  DO] 
suchthat  V  *  loeal-var-of[* .  DO] 
do  Try  Reformulate  V  as  global-expression 

[ Try  changing  ail  local  variable  ralarencas  to  global  references.] 
References:  1.4 
|  End  Method 


|  Method  FoldGanerldntoRalatlon 


I 


Goal:  Isolate  X  |  expression 
Action:  1)  Globalize  X 

2)  Apply  FOCD.WTO.REUATION(X) 

[Straightforward  told  into  derived-relation.} 
References :  1 .3, 1 .1 7, 3.3 
|  End  Method 


F.IO.  Maintainlncrementally 


|  Method  ScailerMaintenanceForDerlvedRelatlon 

Goal :  Maintainlncrementally  DR  |  derived-relation 
Filler:  a)  -recurslve(DR) 

Action:  1)  Flatten  body-of  [DR] 

2)  forall  locat1on-reference[BR,  $,  DR] 
do  forall  locat1on-raference[BR,  L.  epee) 
do  begin 

Apply  lWTBOOUCe.MAINTENANCE.COOe(DR  L) 

Purify  L 
end 

[To  maintain  a  derived  relation  DR.  find  everywhere  the  base  relations  of  DR  are  changed  and 
such  code  in  to  maintain.  Make  sure  that  all  base  relations  are  simple  before  maintenance  and 
that  all  code  is  pure  after.} 

References:  1.6,  1.11,  1.18,  3.4,  5.2 
|  End  Method 


F.10  Maintainlncrementally 
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Method  IntroduceSeqMaintenanceDemon 

Goal:  Maintainincrementally  DR | derived-relation 
Filter:  a)  g1st-type-of[parameter-of  [DR], 

sequence] 

Action ■.  l)  Reformulate  body-of[DR] 

72 

as  tempo  rally -o  rde  red  act -idiom 
2)  Apply  INTRODUCE.SeO.MAINTENANCE.DEMON(DR) 

[One  way  of  maintaining  a  derived  sequence  is  to  first  change  the  definition  into  a  temporal  order 
-  UxllPMasol  everbelore )  ordered  temporally  fty  P(x))  -  and  then  set  up  a  demon  with  trigger 
P(x)  to  add  elements.] 

References:  1.11,  5.2 
End  Method 


F.1 1 .  Map 


|  Method  ShowNoChange 

Goal:  Map  C|  *e onstraint  -(start  P) 
between  E1.E2 

Action:  l)  Show  unchangeo„betweenevents(  P ,  El.  E2) 

2  )  Apply  REMOVE.UNCMANGEO.CONSTRAIW  ( C ) 

[The  direct  approach.] 

References:  4.16 
|  End  Method 


‘Patterns  can  be  predefined  and  named.  In  this  case.  ({x||P(x)  gjfil  everbeforel  ordered  temporally  fey  start  P(x)) 


|  Method  ChooseElemantOfSet 


Goaf :  Map  C|  +  constraint 

Filter:  a)  g1*t-type-of(£  |constra1nt-body[C],  existential] 

Action :  l)  Show  elem£nt_c*_SET(  X ,  E) 

2)  Apply  CHOOSe_ELEM£NT(X.  £) 

{Try  replacing  the  existential  set  with  one  of  its  elements.] 

References:  unused 

|  End  Metnod  | 


|  Method  CasIfyOemon 


Goal  :  Map  0 1  demon 
Action:  1)  Casify  0 

2)  fora'll  case-of[X,  D]  do  Map  X 

{T ry  mapping  by  case  analysis.] 

References :  4.3.  6.1.  6.3.  6.6.  6.13.  6.16.  6.18 

|  End  Method 


I 


|  Method  UnfoldOemon 


Goaf:  Map  D| demon 

Action:  l)  forall  tr1gger-locat1on[D,  L,  spec] 
do  Untold  D  at  L 

[To  Map  a  demon,  untold  It  where  appropriate  ] 

References:  4.3,  6.1,  6.3,  6.6,  6.13,  6.16,  6.20 
|  End  Method 
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Method  StoreExplIcitly 


Go  al:  Map  OR  |  derived- relation 
Pillar:  a)  static  (OR) 

Action:  1)  Show  fiNfTE.EXPt  (Cation ( OR ) 

2)  Apply  INrTIAU2E_M£MO.RELAT(ON(M ,  DR) 

3)  forall  location-reference[DR,  L,  spec] 

do  Apply  REPLACE-REF-wrrH-MEMO(L,  M) 

4)  Apply  remove.unreferenceo.relation(DR) 


[You  can  explicitly  compute  a  static  Periled  relation  given  a  tinHe  number  o  1  resulting  db 
insertions.] 

References:  1.10,  6.1,  5.4,  5.5,  5.8 


End  Method 


|  Method  UnfoldDerlvedRelation 


Goal:  Map  OR  \  derived- relation 

Action:  1)  forall  1  ocat  1on-r«f#rence[DR .  L.  spec] 
do  Untold  OR  at  l 


[One  way  of  eliminating  a  derived  relation  is  to  unfold  it  at  ns  reference  points.] 
References:  1.11  5.1.  5.4.  5.5,  5.8 
|  End  Method 


|  Method  ConpuieNewValue 


Goal:  Map  Ul update  X  £f  Y  Z  where  P 
Action :  1 )  Apply 

compute.derived.object.from.constraint  ( U ) 


(Reformulate  2  as  derived  object  using  P.] 
References:  4.18 
|  End  Method 


|  Method  MoveConstralntToActlon 


I 


Goal:  Map  C| repairs 
Action:  1)  Reformulate  C  as 

raquira  P  |i  list  E  | action-event 

2)  Show  last.acton  ( A  |  action .  E) 

3)  Apply  MOVt.CONST*»AINT.TO.ACTION{C.  A) 

l If  a  constraint  C  is  on  soma  action  event  Eat  A,  attach  tha  constraint  to  AJ 
Ratarancas :  4.7.  4.S,  4.10,  4.12,  4.13.  4.15,  4.16 
|  End  Method 


|  Method  NotXUntlU 

Goal :  Map  R  |  ♦  constraint 

Action:  1)  Reformulate  R  as  a  constraint  f  ...  until  E 

2)  Show  impued.bv(  P .  -E) 

3)  Apply  BEMOVE_VACUOUS_CONSTBAINT<R) 

[P  uMl  E  **  true  when  -E  implies  P] 

References:  4.7.  4.9.  4.10.  4.12.  4.13.  4.15.  4.16 
|  End  Method 


I 


|  Method  TMggerlmpl  lesConstralnt 


Goal:  Map  R| raquira 

Filter:  a)  componenl-of[R,  D| demon] 

Action:  l)  Ralormulata  R  as  require  P  ^  ThisEvent 

2)  Show  iMPueD_BY(P,  trlgger-oflO]) 

3)  Apply  REMOVE.Mn.eO.REOUmEMeNT(R) 

[II  a  requirement  it  part  ol  a  demon,  try  showing  that  It  it  implied  by  tha  demon  t  trigger.] 

References :  4.7,  4.9.  4.10.  4.12.  4.13.  4.16,  4.16 

|  End  Method  I 
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Method  CasIfyPosConstralnt 

Goal  :  Map  C  |  *  constraint 
Action :  1)  Casity  C 

2)  fora'll  case-of[X.  C]  do  Map  X 

[ Try  mapping  by  case  analysis.) 

References :  4.7.  4.9,  4.10.  4.12.  4.13.  4.16,  4.16 
End  Method 


|  Method  UnfoldConstralnt 

Goal:  Map  C\  constraint 

Action:  1)  forall  1oeat1on-v1olat1on[V,  C]  do  Untold  C  at  V 

[Find  all  placas  constraint  might  be  violated  and  untold  maintenance  coda.) 
References :  unused 
|  End  Method 


|  Method  MapConstralntAsDemon 
Goal:  Map  C|  constraint 

Action:  1)  Reformulate  C  as  always  prohibit  P 

2)  Show  implied_by  ( Q ,  P) 

3)  Apply  eeF0HMUL»TE.C0NSTa»iNT,as.0EM0N(  C .  0.  Dfl#w) 

4)  Map  0„#w 

[To  map  a  prohibitive  constraint,  first  choose  some  predicate  0  that  Is  always  true  when  the 
constraint  Is  violated,  and  then  introduce  a  demon  whose  trigger  is  0  end  whose  body  is  a 
requirement  of  -P.) 

References:  4.1 
|  End  Method 
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|  Method  MalntalnDarlvadRalatlon  | 

Goa/:  Map  OR | darivad-ralotion 
Filtar :  a)  -static[DR] 

Action:  1)  Maintainlncramantally  OR 

(Ont  way  oi  mapping  a  darlvad  ralation  is  to  maintain  it  explicitly.) 

Ralarancas :  1.10,5.1,  6.4,  6.6,  6.8 

|  End  Method  | 


|  Method  MapRandomToForwardEnuin 


Goal:  Map  G  |  random-alamant-genarator 
Action:  1)  Show  no_succeesor„reliance(G) 

2)  Apply  REFWE_8ET_ENUM_TO_FOnwABD_SEO(  G  ) 

{You  con  map  a  random  (or  A ID)  ganarator  to  a  forward  ganarator  undar  cartain  conditions.) 
Ralarancas:  TextPraprocessor 
|  End  Method 


I 


I 


|  Method  MapRandomToBackwardEnuin 

Goal:  Map  G  |  random-aiement-generator 
Action:  1)  Show  no_predecesior_reiiance(  G ) 

2)  AppIv  REFwe.8rr.ENUM.TO.iACxwAA0.8eo(  G ) 

{You  can  map  a  random  lor  ND)  ganarator  to  a  backward  ganarator  undar  cartain  conditions.) 
Ralarancas:  unused 
|  End  Method 
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|  Method  MapByConsol idatlon  | 

Goal:  Map  D | demon 

Filler :  a)  match.pattern[demon,  D2,  spec] 
b)  D  *  02 

Action:  l)  Consolidate  D  and  02 

[To  map  D.  find  some  other  demon  D2  and  consolidate.] 

References:  4.3.  6.1.  6.3,  6.6.  6.13.  6.15.  6.16 
|  End  Method  | 


F.12.  Purify 


|  Method  PurifyDemon 


Goal:  Purity  A j action  In  0| demon 
Action:  1)  Remove  t  from  0 

[Remove  unpure  statement  L  from  D.] 
References :  5.10,  5.1 4 
|  End  Method 


I 


I 
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|  Method  ReformlocalAsHrst  I 

Goa/:  Refo rmulata  V|  variable  as  q/obe /-expression 

Filter:  a)  oatten-matchfretatlon  name  (seo  I  sequence  af,  typo)  daf;. 

R.  spec] 

6)  domaln-type-of  [type ,  V) 

Action:  1)  Raformulata  V  as  f Irstf namof )) 

(II  you  can  find  a  sequence  containing  tha  same  type  of  06/ects  as  V  then  you  may  be  abla  to 
changa  V  into  a  spacltic  reference  to  the  sequence.; 

References :  1.5 

|  End  Method  I 


|  Method  ReformLoealAsLast  I 

Goal:  Raformulata  V  |  variabla  as  global-axprassfon 

Filter:  a)  patter -mate hfrel  at  Ion  name  fseolsenuance  £f  type)  def;, 

R.  epoe] 

b)  domaln-type-of  (type,  V] 

Action:  1)  Raformulata  V  as  last/ name(*) ) 

[If  you  can  find  a  saquanca  containing  the  same  type  of  objacts  as  V  than  you  may  ba  abla  to 
changa  Vinto  a  spaclflc  rafaranca  to  tha  saquanca.] 

Ratarancas :  1 .5 

|  End  Method  I 


|  Method  ReformulateEverMoreAsDurlng 

Goa/:  Raformulata  X  as  (-V  during  E) 

Fittar:  a)  g1st-type-of[X,  predicate] 

Action  :  1)  Raformulata  X  as  (-Y  asof  eve  mo  re ) 

2)  Show  impueo.by(Y,  E) 

3)  Apply  wroeM-EvERMonE  AS-uNTit  ( X ,  E) 

](-Y  asof  evermore)  ■»  (-  Y  during  E)  whara  Y  implias  E] 
Ratarancas:  unused 
|  End  Method 


I 


I 


•T  •*  .  .*  4"w  V_  * -J 


A.  V*  \  \  . 


F.13  Reformulate 


PAGE  421 


Method  ReformulateUntllAsEvermore 


Goal:  Ratormulata  U I  until  P  as  asof  evermore 
Action:  1)  Show  nuu.OCCjbremce( until -even t[S]) 
2)  Apply  Urm._NEVER_TO.EVERMO«E(S) 

[P  until  navar  •  P  asof  evermore) 

References:  unused 
|  End  Method 


|  Method  ReformulateAsCondByEmbeddlng 


Goal:  Reformulate  X  as  If  True  then  X 
Action:  1)  Apply  EMBEOJN.COND(X) 

(X  a*  If  Trua  than  X)1 
References:  TextPreprocessor 
|  End  Method 


I 


|  Method  RenameVar  | 

Goal:  Ratormulata  VI  |  variable-declaration  as 

V2 1  variabla-dacla ration 
Fittar :  a)  scoped-InlVl  S] 

Action:  1)  Show  introouceable.var.nah*  ( V2 ,  S) 

2)  Apply  rename_var(  VI ,  V2,  S) 

[Raplaca  all  occurrences  of  VI  with  V2  in  $  attar  showing  that  V2  does  not  conflict  with  scopad 
variables  already  defined  within  S.J 

References:  2.12 

|  End  Method  | 


|  Method  ReformuiateReiativeRetrievalAsLast 

Go  a/ :  Reformulate  RS  |  relative-sequence-retrieval 

as  * x  |  obyocf *  ljil(  Sa q  |  sequence ) * 
Action:  1)  Reformulate  RS  as 

*x  Immediately  before  y  w£i  (Seq  concat  i) 

2)  Equivalence  y  end  z 

3)  Apply  cmange.to_RET«ievai._of_last(RS) 

lx  immediately  before  v  wrt  (Seq  concat  v)  •  »  » last(Sea)! 
References:  1.14 
I  End  Method 


|  Method  ReformulateRelatlveRetrievaiAsFirst 

Goal :  Reformulate  RS  |  relative-sequence- retrieval 

as  ”x  |  o6/'ecf«Ux51( Seq  |  sequence )■ 
Action  :  1)  Reformulate  RS  as 

"x  immediately  after  y  w£i  (z  concat  Seq) 

2)  Equivalence  y  and  z 

3)  Apply  CHANQE.TO.RET«tEVAL.OF.rtRST(RS) 

lx  immediately  after  y  wrt  (v  concat  Sea)  »  «  «  first  (Seo)l 
References:  1.14 
I  End  Method 


|  Method  Ref  omul  ateAsObJect 

Goal:  Reformulate  SR|  lost-retrieval  as  0 1  object 
Action:  1)  Reformulate  parameter-of[* ,  SR]  as  (S  concat  0) 
2)  Apply  stMPi.ifY_LAST(SR) 


/last IS  concat  O)  ■*  0] 
References :  1 .1 6, 1 .20 
End  Method 


|  Method  Special IzeRandom  | 

Goa/:  Reformulate  X| RANDOM  as  Y 
Action:  1)  Show  non_£mpty_speciali2at©n  ( Y ) 

2)  Apply 

REPLACE  JWNDOMWITH.SPECIALI2ATION { X  Y ) 

[You  can  always  raplaca  RANDOM  with  a  more  specialized  avant  It  you  can  show  tha  naw 
eventdoes  not  ram  ova  all  choicas.] 

References :  4.6 

|  End  Method  | 


|  Method  ReformulateExIstentlalTrlggar  | 

Goal:  Reformulate  Tltrlaoer  -3  o||R(o)  as  R(o‘) 

Action:  1)  Show  triooep.QEnERauzable(T} 

2)  Apply  GENERALlZE.TRIOaER(T) 

[You  can  ratormulate  an  existential  trigger  Into  a  universally  quantified  one  under  certain 
conditions .) 

References:  6.11 

|  End  Method  | 


F.14.  Remove 


|  Method  RemovaFromDemon 


I 


Goa/:  Remove  A  \  action  from  D| demon 
Action:  1)  Globalize  A 

2)  fora'll  tr1ggtr-1ocat1on{D2|  demon,  body-of[*,  D],  spec] 
do  Apply  MOVE.rrATEM£WT.TO_D£MON(  X ■  D2  ) 


[Find  all  demons  that  trigger  from  D  and  move  the  action  A  there.! 
References:  6.11,8.16 
|  End  Method 


I 
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|  Method  RemoveRelatlon 


Goa/:  Remove  R | relation  from  spec 
Action:  1)  forall  reference*locat1on[R,RR,spec] 
do  Remove  RR  from  apae 
2)  Apply  REMOVEJJ*REFEREHCED_RELAT10n(  R  ) 

[You  can  remove  a  relation  It  you  can  remove  all  references  to  It  ] 
References:  1.1.  2.1,  3.1 
|  End  Method 


I 


|  Method  ReplaceRefWIthValue 


Go  el:  Remove  RR  |  bese-rolation-roforenco 
Action:  1)  Show  valUE_knOwn(  R .  V) 

2)  Apply  REPLACE_R£F_WITH_  VALUE  {  R  V) 

[One  way  ol  getting  rid  of  a  non-derived-relation  reference  Is  to  replace  It  with  Its  value.] 
References:  1.12.  1.19,  2.2.  3.2 

|  End  Method 


I 


I 


|  Method  MegaMove 


Goal:  Remove  RR  |  relation- reference  from  spec 
Filter:  a)  component-of [RR .  Y | expression] 
Action:  1)  Isolate  Y  in  OR | derived- relation 
2)  Maintelnlncrementelly  DR 


[Remove  the  relation-reference  RR  by  moving  it  directly  after  the  locations  It  is  assigned. J 
References:  1.2,  1.12.  1.19.  2.2,  3.2 
|  End  Method 


I 
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Method  PostionalMegaMove  N 

Goal:  Remove  RR  |  rotation- rat  wane*  from  spec 
Fitter:  a)  component-of[RR,  Y | expression] 

b)  gist-type-of  [sequence,  argument-of [».  RR]] 

Action:  l)  Reformulate  Y  as  PR | positional-retrieval 

2)  Isolate  PR  in  DR | derived-relation 

3)  Maintainlncramantally  DR 

[One  way  of  getting  rid  of  a  rataranca  to  a  sequence  is  to  reformulate  It  as  part  o 1  a  positional 
retrieval,  and  then  megamove  It.] 

References:  1.2.  1.12,  1.19,  2.2.  3.2 

End  Method 


|  Method  RemoveVarlable 

Goal:  Remove  V|  variable  from  S|  scope 
Action:  1)  fora!!  reference-1ocation[V.VR,S] 
do  Remove  VR  from  S 
2)  Apply  REMOVE_UNREFERENCED.yARlABU(V) 

[You  can  remove  a  variable  If  you  can  remove  all  references  to  It.] 
References:  TextPreprocessor 
I  End  Method 


|  Method  RemovoByObjectlzIngContext 

Goal:  Remove  RR  |  relation- reference  from  spec 
Fitter :  a)  component-of[RR .  Y | expression] 

Action:  1)  Reformulate  Y  as  object 

[One  way  of  getting  rid  of  a  relation  reference  which  Is  embedded  In  context  Y  is  to  reformulate  Y 
as  an  explicit  object.] 

References:  1.2.  1.12.  1.19.  2.2.  3.2 

I  End  Method 


Method  RemoveUnusedAction 


Goal :  Remove  A  |  action 

Action:  1)  Show  action_ie_unnoticed( A) 

2)  Apply  REMOVE-UNNOTICEDACrriON(A) 

f  Show  that  tha  currant  action  is  aithar  not  used  or  superseded  by  a  subsequent  action.} 
References:  1.21,3.5,  5.11.  5.16 
|  End  Method 
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|  Method  BabyWIthBathWater 

Goal:  Remove  X 

Filter:  a)  X  component -of  Y 

Action:  l)  Remove  Y 

{On«  drastic  mathod  of  removing  X  Is  to  remove  strucutra  X  Is  embedded  in.) 
Raiarancas:  1.2.  1.12.  1.1S.  1.21,  2.2.  3.2.  3.S.  5.11,  6. IS 

|  End  Method 


F.1 5.  Show 


|  Method  Conjunctlmpl lesConjunctArm 

Goal:  Show  X| conjunction  Implies  Y 
Filter:  a)  unbound[Y] 

b)  c  o  n j  u  c  t  - »  rm[A  |  logical-expression ,  X] 
Action:  1)  Assart  X  Implies  A 

/fPj  and  P2  and  ...Pn>  implias  Pf 
References:  4.2 
|  End  Method 


|  Method  ShowDysteleologlcal 

Goal:  Show  actionJa.unnoticed(U  |  update) 

Filter:  a)  update-relat1on-of(R.  U] 

b)  -locatlon-referencelR,  $,  spec] 

Action:  l)  Assart  actionJa.unnoticed(U) 

[It  you  are  trying  to  show  that  an  updata  Is  unnoticed,  show  that  It  is  never  referenced.] 
Raiarancas:  1.22 
|  End  Method 


J 


:1  S 


F.15  Show 
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Method  ShowUpdateGIvesValue 

Goal:  Show  vauje_known{R| relation- reference,  V) 

Filter:  a)  match-pattern[updefe,  U,  spec] 

b)  name-of(R]  •  update-relatlon-of]*,  U] 
Action:  1)  Show  UPOATE.VALU£.MOUJS(U,  R) 

2)  Assert  value_known(R  ,  new-va1ue-of[V  II] ) 

[Find  the  last  update  ol  R  and  show  that  the  newvalue  is  still  valid.] 
References :  2.3 
End  Method 


|  Method  ShowNewValueSlillValid 

Goal  .  Show  update.value_ho.ds(U|  update,  R|  relation  reference) 

Filter:  a)  name-of[R]  »  update- relatlon-of]*,  U] 

Action  :  1 )  Show 

uNCHANGED.BFnwEEN_EVENTS(naw-value-of[* .  U],  U.  R) 

3)  Assert  UPOATE.VALUE.MOLDS  ( U  ,  R) 

[To  show  that  the  new  update  value  is  Still  around  at  ft,  show  that  the  update  value  has  not  been 
changed  before  ftj 

References :  2.4 
|  End  Method 


|  Method  MovelntervenlngUpdate 

Goal:  Show  unc«*nQed.between_locations{V|  relation  reference. 

U | update, 

R  |  relation  reference) 

Filter:  a)  pattern-match[updafe,  l,  spec] 
b)  update-re1at1on-of(V,  l] 

Action:  1)  Show  COMPUTATIONAUr-BFWEEN[L ,  U,  R] 

2}  ComputeSequentially  R  before  L 

,//  an  intervening  update  of  V  exists,  move  It  alter  ft./ 

References:  2.5 
|  End  Method 
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F.16.  Simplify 

In  this  section,  we  ns*  the  trenetormetione  that  make  up  the  simplification  subcatalog.  For  further  details,  see  section 
E.14. 


Simplifying  a  conjunction 


(and)  ■*  true 

(and  ...  false  ...)  ■»  false 

(and  p)  <•  p 

(and  ...  true  ...)  *»  (and  ...) 

(and  ...p..,p...)  ■*  (and  ...  p  ...) 

(and  ...  (and  p  q  r)  . . . )  •  (and  ...  p  q  r  ...) 
(and  . . .  p  . . .  >p  . . . )  false. 


Simplifying  a  disjunction 

(or)  «•  True 

(or  ...  true  ...)  true 

(or  p)  «*  p 

(or  ...  false  . . . )  »  (or  . . . ) 

(or  ...  p  ...  p  ...)  ■*  (or  ...  p  ...) 

(or  ...  (or  p  q  r)  ...)  ■»  (or  ...  p  q  r  ...) 

(or  . . .  p  . . .  -p  . . . )  (or  ...  true  ...) 

Simplifying  a  negation 

(not  (not  p))  »  p 
(not  true)  false 
(not  falee)  •  true 


fcs 
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|  Method  ScatterComputatlonOf Demon  | 

Goal:  Unfold  0 1 demon  at  L 

Filter:  a)  trtgger*1ocat1on[D,  L,  $] 

Action :  1)  Apply  unfolo„demon.cooe(D  L) 

2)  Purify  L 

[To  unfold  a  damon  D  at  a  triggar  point,  stick  In  coda  to  computa  If  and  maka  sura  L  Is  within 
implementable  portion  of  spac.] 

Pafarancas :  6.4 , 6.2 1 

|  End  Method  I 


r; 


|  Method 


UnfoldAtomlc 


I 


Goal:  Unfold  A  |  atomic 

Action:  1)  Show  sequential  ORDERiNG(0|order»»fl,  A) 

2)  Show  superfluous.  atomic(  A ) 

3)  Apply  unfold-atomic(  A .  0) 

[You  can  unfold  an  atomic  ft  you  can  show  that  there  exists  some  valid  sequential  ordering  of  the 
statements  and  that  no  demonic  or  intarancing  processes  will  be  affected.] 

Pafarancas  :  2.7,5.13,5.17 

|  End  Method  I 


\\* 

\\ 


V, 
«•  - 
V 


|  Method  Unfolds ImpleSB 


Goat:  Unfold  SBIbooln  S  end 

Action  :  1)  Aoolv  unfold.Simple.n£STED.Blocf(  SB ) 

f...baoln  s  and...  m  ...a...} 

Pafarancas:  TextProeprocessor 
|  End  Method 


I 


«• 


G  Selection  Catalog 
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Appendix  G 
Selection  Catalog 

Q.1 .  Catalog  Notation 

Selection  rules  will  be  presented  using  the  following  format: 

Selection  Rule  <name> 

IF:  ^selection  expression^1 
THEN:  [Selection  action>]1 
[optional  comments] 

References:  list  of  steps  where  rule  used  in  selection  process 
End  Selection  Rule 

A  rule's  <name>  is  used  to  give  it  a  unique  textual  handle  and  is  intended  to  give  a  short 
description  as  well. 

The  references  list  points  into  the  router  development  in  appendix  C.  The  items  of  the  list  are 
steps  in  which  the  rule  played  an  active  part  in  selecting  a  method. 

For  an  explanation  of  the  remaining  fields,  see  chapter  7. 

The  selection  rules  are  organized  in  the  following  manner: 

□  Method  Specific  Rules:  grouped  here  as  in  appendix  F,  around  the  set  of 
development  goals.  Each  development  method  in  appendix  F  will  be  listed  here 
along  with  a  list  of  steps  where  it  was  competing;  bold  faced  steps  mark  steps  in 
which  the  method  was  the  one  finally  selected.  Following  each  method  are  the 
selection  rules  pertaining  to  it  (possibly  none). 

□  Action  Ordering  Rules:  listed  after  specific  method. 

□  Method  Ordering  Rules:  listed  at  the  end  of  each  goal  section. 


PAGE  434 


SELECTION  CATALOG 


□  Problem  Solving  Resource  Rules:  listed  in  section  G.19. 

□  General  Rules:  listed  in  section  G.20. 


G.2.  Casify 

Binary  Split  (4.8,  4.11, 4.14) 


|  Select  ionRula  "BlnarySpl 1 1 1  I 

IF  a)  •BlnarySplit  Is  a  candidate 
b)  Good  cholca  for  Q  It  known 
THEN  +2 

[Good  cholca  H  /iava  a  0  in  mind.] 

|  End  Salaction  Rula  | 


|  SelectionRule  •BlnarySpI  1t2  I 

IF  a)  •BlnarySplit  Is  a  candidate 
b)  Good  cholca  for  Q  Is  unknown 
THEN  -2 

[Bad  cholca  H  don't  hava  a  0  In  mind  J 
Ratarancas:  4.8,  4.11,  4.14 

|  End  Salaction  Rula  | 


CaaHyConjunctiveTrigger  (B.2 , 6.1 3) 

CasifySuparTriggar  (5.18, 5.1 9) 

Paatlnduction  (4.8, 4.11, 4.14) 

CaalfyFromUntilEvarConatraint  (4.S,  4.11, 4.14) 
CaatfyAroundEvant  (4.8, 4.11, 4.14) 
RafromulataAaMuxCaaa  (TaxtPraproceesor) 


G.3  ComputeSequentially 
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G.3.  ComputeSequentially 

ConaolidateToMakeSequential  (2.8) 


|  SelectionRule  ‘Consol IdateToMakaSaquential  | 

IP  a)  Consol IdateToMakeSequenttal  Is  a  candidate 
THEN  +2 
References:  2.8 

|  End  Selection  Rule  | 


MoveOutOf  Atomic  (2.6) 


|  Select ionRule  ‘MoveOutOf Atomic  | 

IP  a)  MoveOutOf Atom 1c  Is  a  candidate 
THEN  ♦ 2 

Rtfertncts :  2.6 

|  End  Selection  Rule  | 


SwapUp  (2.13) 


|  SelectionRule  ‘SwapUp  | 

IF  a)  SwapUp  Is  a  candidate 
THEN  +2 
References:  2.13 

|  End  Selection  Rule  | 


G.4.  Consolidate 


MergeDemons  (2.9, 4.4, 6.7, 6.1 5) 
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|  SelectionRule  •MargaDtmons  I 

IP  a)  MargeDemons  1$  a  candidate 
THEN  *  5 

References :  2.9,  4.4,  6.7,  6.15 

|  End  Selection  Rule  I 


|  SelectionRule  TrlggersAlmostEquiv  | 

IP  a)  MargeDemons  Is  selected 

b)  Triggars  dtffar  only  in  variable  renaming 
THEN  action-2  >  actlon-l 
[The  first  goel  will  fall-out  as  side-effect  of  second.} 

|  End  Selection  Rule  I 


ConsolidateEnumerationLoops  (T  extPreprocessor) 


ConsolidateSimpleCondsI  (unused) 


ConsolidateSimpleCoRds2  (Text  Preprocessor) 


G.5.  Equivalence 

EquivalenceCompoundStructuresI 


|  SelectionRule  •EquivalenceCompoundStructuresI  I 

IP  a)  EquivalenceCompoundStructuresI  Is  a  candidate 
THEN  +5 

|  End  Selection  Rule  I 


EquivalenceCompoundStructuresS  (2.10, 6.1 2, 6.1 7) 
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|  SelectionRule  *Equ1valenceCompoundStructures2 

IF  a)  Equ1valenceCompoundStructures2  Is  a  candidate 
THEN  +2 

References:  2.10.  6.12,  6.17 
|  End  Select  Ion  Rule 


Anchorl  (1.15,  2.10,  2.11,  4.5.  6.8,6.12,  6.18) 


|  SelectionRule  "Anchorla 

IF  a)  Anchorl  Is  candidate 
b)  X  |  object 
THEN  *2 

References:  2.4,  6.12,  6.18 
|  End  Selection  Rule 


|  SelectionRule  ‘Anchorlb 

IF  a)  Anchorl  is  candidate 
b)  Y  |  RANDOM 
THEN  *5 
|  End  Selection  Rule 


|  SelectionRule  'Anchorlc 

IF  a)  Anchorl  Is  candidate 

b)  Y  |  derived-reletion-reference 

c)  Deflntlon  of  Y  reformulatable  as  X 
THEN  *  2 

References:  6.8 
|  End  Selection  Rule 


Anchor2  (1.15, 2.10.  2.1 1 , 4.6. 6.8.  6.1 2. 6.18) 
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|  SelectionRule  *Anchor2a  | 

IP  a)  Anchor2  Is  candidate 
b)  Y  |  object 
THEN  +2 

R»l»r»nc0s :  1.16.  2.11,  6.12,  6.16 

|  End  Selection  Rule  | 


|  SalactionRula  *Anchor2b  | 

IP  a)  Anchor2  Is  candidate 
b)  X | RANDOM 
THEN  *5 
References:  4.6 

|  End  Selection  Rule  | 


|  SelectionRule  *Anchor2c  | 

IP  a)  Anchor2  Is  candidate 

b )  X  |  cfer/VeO-re/ef /on- reference 

c)  Deflntlon  of  X  reforaiulatable  as  Y 
THEN  ♦ 2 

|  End  Selection  Rule  | 


AddNewVar 


|  SelectionRule  •AddNewVar  | 

IP  a)  AddNewVar  Is  candidate 
THEN  ♦  2 

|  End  Selection  Rule  | 


Method  Ordering  Rules 


v 


G.5  Equivalence 
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|  SelectionRule  EquIvVarsl 

IF  a)  Method  ‘Anchorl  Is  a  good  candidate 

b)  Method  *Anchor2  Is  a  good  candidate 

c)  X  and  Y  are  variable  names 
THEN  Rely  on  user  to  choose 


/The  manipulation  ot  names  is  viewed  as  Important  and  currantly  rasts  in  tha  hands  ot 
tha  usar.] 

Ratarances :  2.11,  6.12,  6.18 

|  End  Selection  Rule  | 


if  correspondecne  i  has  more  type  matches  than  corresp  2  then  choose  first 


if  corresp  1  has  more  usage  matches  (trigger  vsrs)  than  corresp  2  then  choose  first. 


if  tried  equivcompst  before  try  addnewvar  now  else  vice  versa 


G.6. Factor 


FactorDBMaintenancelntoAction  (6.5) 


|  SelectionRule  •FactorDBMaintenancelntoAction 

IF  a)  FactorDBMaintenancelntoAction  Is  a  candidate 
THEN  *2 


References:  6.5 


End  Selection  Rule 


G.7.  Flatten 


Flatten  (1.9,  5.3,  5.7) 


SelectionRule  ‘Flatten 

IF  a)  Flatten  Is  a  candidate 
THEN  *2 

Ratarancas :  1.6,  6.3,  6.7 
End  Selection  Rule 
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G.8.  Globalize 

GlobalizeAction  (5.10, 5.15) 


|  SelectionRule  ‘Global IzeActlon 

IF  a)  Global IzaActlon  Is  a  candidate 
THEN  *2 

References :  6.10.  6.15 
|  End  Sanction  Rule 


GlobalizeDerived  Object  (1.4) 


|  SelectionRule  ‘Global IzeDerlvedObject 

IF  a)  GlobalizeDerivedObject  Is  a  candidate 
THEN  +2 
References :  1.4 
|  End  Selection  Rule 


G.9.  Isolate 

FoldGeneridntoRelation  (1 .3, 1 .1 7, 3.3) 


|  SelectionRule  ‘FoldGeneridntoRelation 

IF  a)  FoldGeneridntoRelation  Is  a  candidate 

THEN  +2 

[If  applicable,  use  It.] 

References:  1.3,  1.17,  3.3 
|  End  Selection  Rule 


G.10  Maintainincrementally 
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G.10.  Maintainincrementally 

ScatterMaintenanceForDerivedRelation  (1.8, 1.11, 1.18, 3.4, 5.2) 


SelectionRule  •ScatterMalntenanceForDerlvedRelation 

IF  a)  ScetterMaintenenceForDerivedReletion  Is  a  candidate 
THEN  +2 


References:  1.8,  1.11,  1.18,  3.4,  6.2 
|  End  Selection  Rule 


introduceSeqMaintenanceDemon  (1 .1 1 , 5.2) 


|  SelectionRule  •IntroduceSeqMaintenanceDemon 

IF  a)  IntroduceSeqMaintenanceDemon  Is  a  candidate 
THEN  +1 

References:  1.11,  6.2 
|  End  Selection  Rule 


Method  Ordering  Rules 


|  SelectionRule  MalntDRl 

IF  a)  IntroduceSeqMalntenacneDemon  Is  a  flood  candidate 

c)  ScatterMalntenanceForDerlvedRelatlon  is  a  good  candidate 

d)  DR  has  a  complex  definition 

THEN  ScatterMalntenanceForDerlvedRelatlon 

>  IntroduceSeqMalntenacneDemon 

[A  comp/ex  def/n/flon  mss  ns  a  large  numbsr  of  new  demons  must  Oe  Introduced./ 
References:  5.2 
|  End  Selection  Rule 
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G.ll  Map 
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|  SelectionRule  ‘StoreExpl Icltly  I 

IF  a)  StoraExplicitly  Is  candidate 
THEN  +2 
References:  6.4 

|  End  Selection  Rule  I 


MapByConsolidation  (4.3, 6.1, 6.3, 6.6,6.13,  6.1 5) 


|  SelectionRule  •MapByConsol  Idatlonl  I 

IF  a)  MapByConsolidation  Is  a  candidate 

b)  D  does  not  trigger  on  an  observable  event 

c)  D2  triggers  on  an  observable  event 
THEN  ♦  1 

References:  4.3,  6.1.  6.3,  6.6,  6.13 

|  End  Selection  Rule  I 


|  SelectionRule  *MapByConso1 1dat1on2  [ 

IF  a)  MapByConsolidation  Is  a  candidate 
b)  02  triggers  randomly 
THEN  +2 

References:  4.3,  6.1,  6.3,  6.6,  6.13,  6.15 
|  End  Selection  Rule  I 


|  SelectionRule  •MapByConsol  1dat1on4  I 

IF  a)  MapByConsolidation  Is  a  candidate 

b)  02  Is  not  within  Implementable  portion 
THEN  -2 

References:  4.3,  6.1,  6.3,  6.6,  6.13,  6.15 

|  End  Selection  Rule  I 


Comput*N«wValu«  (4.1 8) 


G.11  Map 
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MoveConstraintToAction  (4.7, 4.9,  4.10, 4.12, 4.13, 4.1 5, 4.16) 


NotXUntilX  (4.7, 4.9, 4.10,  4.1 2, 4.13, 4.15, 4.16) 


TriggerlmpliesConstraint  (4.7, 4.9, 4.10, 4.12, 4.13, 4.15, 4.16) 


CasifyPosConstraint  (4.7, 4.9,  4.10, 4.12,  4.13,4.15, 4.16) 


UnfoldConstraint  (4.1) 


|  SelectionRule  'UnfoldConstraint 

IP  a)  UnfoldConstraint  is  a  candidate 
t>)  Backtracking  solution  is  possible 
THEN  +2 


End  Selection  Rule 


MapConstraint  As  Demon  (4.1 ) 


|  SelectionRule  'MapConstralntAsDemon 

IP  a)  MapConstralntAsDemon  is  a  candidate 
b)  A  predictive  solution  is  possible 
THEN  +2 


References:  4.1 


|  End  Selection  Rule 


MaintainDerivedRelation  (1 .10, 5.1 , 5.5.  5.8) 


|  SelectionRule  'MaintainDerivedRelation 

IP  a)  MaintainDerivedRelation  Is  candidate 


THEN  '2 


References:  1.10,  6.1.  6.6.  6.6 

End  Selection  Rule 


MapRandomToforwardEnum  (Text  Preprocessor) 


MapRandomToBackwardEnum  (unused) 
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Method  Ordering  Rules 


|  SelectionRule  MapDRla  | 

IF  a)  StoreExplicitly  Is  a  good  candidate 

b)  Number  of  refs  *  recompute  cost  Is  more  costly  than 
number  of  explicit  Insertions 
THEN  StoreExplicitly  >  UnfoldDerivedRelation 
References :  6.4 

|  End  Selection  Rule  I 


|  Select ionRule  HapDRlb  | 

IF  a)  StoreExplicitly  Is  a  good  candidate 

b)  Number  of  refs  *  recompute  cost  Is  less  costly  than 
number  of  explicit  Insertions 
THEN  UnfoldDerivedRelation  >  StoreExplicitly 
|  End  Selection  Rule  I 


|  SelectionRule  MapDR2a  I 

IF  a)  MaintainOerivedRelation  Is  a  good  candidate 

b)  UnfoldDerivedRelation  Is  a  good  candidate 

c)  Number  of  references  *  recompute  cost  Is  high 
THEN  MaintainOerivedRelation  >  UnfoldDerivedRelation 
References:  6.1 

|  End  Selection  Rule  I 


|  SelectionRule  MapDR2b  I 

IF  a)  MaintainDerivedRelation  Is  a  good  candidate 

b)  UnfoldDerivedRelation  Is  a  good  candidate 

c)  Number  of  references  *  recompute  cost  Is  low 
THEN  UnfoldDerivedRelation  >  MaintainDerivedRelation 
References:  6.6.  6.6 

|  End  Selection  Rule  I 


r 
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|  SelectionRule  MapDemonl 

IF  a)  MapByConsol Idation  It  ■  good  candidate 
THEN  MapByConsol Idatlon  >  (CaalfyDamon.  UnfoldOamon) 
References :  4.3 
I  End  Selection  Rula 


|  SelectionRule  MapConstraintl 

IF  a)  CalsfyConstralnt  It  a  good  candidate 
THEN  CalsfyConstralnt  >  UnfoldConstralnt 
References:  4.7.  4.B,  4.10,  4.12.  4.13,  4.16.  4.16 
|  End  Selection  Rule 


|  SelectionRule  MapConstra1nt2 

IF  a)  Coal  it  Map  R |  require 

b)  Ml  | method  Is  a  good  candidate 

c)  M2 1 method  Is  a  good  candidate 

d)  Ml  eliminates  R 

e)  M2  does  not  eliminate  R 
THEN  Ml  >  M2 

[Don  t  muck  around  with  R  it  it  can  be  diractly  aliminatad.] 
Rafarances:  4.8.  4.12,  4.16 
|  End  Selection  Rule 


|  SelectionRule  MapConstra1nt3 

IF  a)  Goal  Is  Map  R|  raquira 

b)  Ml  |  mat  hod  is  a  good  candidate 

c)  M2 1  mat  hod  Is  a  good  candidate 

d)  Ml  moves  R  closer  to  a  non-determlnlstlc  choice  point 

e)  M2  does  not  eliminate  or  move  R 
THEN  Ml  >  M2 


[Moving  a  raquiramant  towards  a.nd  choice  point  is  good.] 
Raiarancas:  4.15 
|  End  Selection  Rule 


! 

v 

i 
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G.13  Reformulate 


PAGE  449 


|  SalactionRula  •RenameVar  | 

IF  a)  RenameVar  It  a  candidate 
THEN  *Z 

References:  2.12,  6.7,  6.14 

|  End  Salection  Rule  | 


Ref  or  mu  late  ActionCal  I  (T ext  Preprocessor) 


ReformulateDerived  Object  (1.13) 


|  SalactionRula  •Reformul ateDerlvedObject  | 

IF  a)  ReformulateDerlvedObject  It  a  candidate 
b)  Definition  of  DO  reforaulatable  at  P 
THEN  +2 

[If  me  body  of  me  derived  relation  looks  llks  It  can  ba  made  to  match  tha  ralormulation 
pattern  than  give  method  a  try.) 

References:  1.13 

|  End  Salection  Rule  | 


ReformulateDerivedRelation  (6.9) 


|  SalactionRula  •ReformulateDerivedRelation  | 

IF  a)  ReformulateDerivedRelation  It  a  candidate 
THEN  ♦  2 
References:  6.9 

|  End  Selection  Rule  | 


ReformulateRelativeRetrievalAstast  (1.14) 


|  SalactionRula  *ReformulateRe1at1veRetr1evalAtLttt  | 

IF  a)  ReformulateRelativeRetrlevalAaLaet  It  candidate 
b)  gel  sequence  of  RS  it  constructed  by  appending 
THEN  42 
References:  1.14 

|  End  Selection  Rule  | 


G.13  Reformulate 


|  SelectionRule  RaformLoc2 

IF  a)  ReformulataLocalAtLatt  it  a  candidate 

b)  R  |  derived-re/af  Son  It  or  da  rad  temporally  by  ttart  l  \  •writ 
THEN  ReformulataLocalAtLatt  >  RaformulataLocalAtFIrtt 
Reference* :  l.S 
|  End  Selection  Rule 


|  SelectionRule  ReformLoc3 

IF  a)  RaformulataLocalAtFIrtt  It  a  candidate 

b)  R | bMf-rmimtion  It  maintained  by  tlmple  prepending 
THEN  RaformulataLocalAtFIrtt  >  ReformulataLocalAtLatt 
|  End  Selection  Rule 


|  SelectionRule  ReformLocA 

IF  a)  ReformulataLocalAtLatt  It  a  candidate 

b)  R | 6ese>refeffon  It  maintained  by  tlmple  appending 
THEN  ReformulataLocalAtLatt  >  RaformulataLocalAtFIrtt 
|  End  Selection  Rule 


G.14.  Remove 

RemoveFromDemon  (S.1 1 , 5.1 5) 


|  SelectionRule  'RemoveFromDemon 

IF  a)  RemoveFromDemon  It  a  candidate 
THEN  +2 

References :  6 . 1 1 ,  5.15 
|  End  Selection  Rule 


RemoveRelation  (1 .1 , 2.1 , 3.1) 
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|  SalaetionRula  •RaplacaRafWIthValual 

IF  a)  RaplacaRafWithValua  is  balng  eonsldarad 

b)  Can  find  a  changa  to  tha  ralatin  bafora  Us  usa 
THEN  *2 

:  2.2 

|  End  Salactton  Rula 


6.14  Remove 
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|  SelectionRule  •Rep1aceRefW1thVt1ue2  | 

IP  a)  ReplaceRefWithValue  It  being  considered 
b)  PR's  argument  It  a  sequence 
THEN  -2 

[Unlikely  that  tha  anttra  saquanca  can  be  unfolded.; 

Ratarancas :  1.12 

|  End  Selection  Rule  | 


MegaMove  (1 .2, 1.12, 1.19, 2.2,  3.2) 


|  Select ionRule  •MegaMove 1  | 

IF  a)  MegaMove  Is  being  considered 

b)  -3  derived  relation  with  deflntlon  Y 
THEN  +2 

Ratarancas:  1.2,  1.12,  1.19,  2.2.  3.2 

|  End  Selection  Rule  | 


|  SelectionRule  *MegaMove2  | 

IF  a)  MegaMove  Is  being  considered 

b)  3  derived  relation  with  deflntlon  Y 
THEN  -2 
Ratarancas :  1.12 

|  End  Selection  Rule  | 


PostionalMegaMove  (1.2, 1 .1 2, 1.19. 2.2, 3.2) 


|  SelectionRule  *Pos1t1ona1MegeMove  I 

IF  a)  PoaitionalMegaMove  It  being  considered 
THEN  +1 

References:  1.2.  1.12,  1.19,  2.2,  3.2 

|  End  Selection  Rule  I 


RemoveVailable  (Text  Preprocessor) 
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RamoveByObjectizingContext  (1.2, 1.12. 1.19, 2.2, 3.2) 


|  SelectionRule  •RamoveByObjectizingContext 

IF  a)  RamoveByObjectizingContext  Is  a  candidate 
b)  V|  positional-retrieval 
THEN  42 


References:  1.18 


|  End  Salaction  Rula 


Removellnused  Action  (1 .2 1 , 3.5,  5.1 1 , 5.1 5) 


|  Salaction  Rula  *RamovaUnusadAct1onl 

IF  a)  RemoveUnusedActlon  is  a  candldata 

b)  A  |  update 

c)  Supargoal  Is  Remove  updatad  relation 
THEN  good  candidate 

[ To  remove  a  reattion  you  generally  have  to  Show  update  Is  unused.] 
References :  1.21,  3.5 
|  End  Salaction  Rula 


SalactionRula  •RemoveUnusedAct1on2 

IF  a)  RamovaUnusadActlon  is  a  candidate 
b)  Supargoal  Is  Purity 
THEN  4  2 


[in  many  cases,  unfolded  code  can  be  slmplfied  away.] 

* 

References:  5.11,  5.15 
End  Salaction  Rula 


RaplaceVariableWitti  Value  (TextPreprocessor) 


BabyWithBathWater  (1.2, 1.12, 1.19, 1.21, 2.2. 3.2, 35, 5.11. 5.15) 


«rvi 


G.14  Remove 
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|  SelectionRule  •BabyWIthBathWaterl  | 

IF  a)  BabyWithBathWater  Is  being  consldarad 
b)  Y  |  conditional 
THEN  t-0 

References:  1.2,  1.16,  2.2,  3.2 

|  End  Selection  Rule  | 


|  SelectionRule  *BabyW1thBathWater2  | 

IF  a)  BabyWithBathWater  Is  being  considered 

b)  Y | demon 

c)  Y  In  Implementable  portion 
THEN  -1 

References :  1.2,  1.12.  1.1B.  1.21,  2.2,  3.2,  3.5 
|  End  Selection  Rule  | 


|  SelectionRule  *BabyW1thBathMater3  | 

IF  a)  BabyWithBathWater  Is  being  considered 
b )  Y  |  -{  conditional, demon) 

THEN  -2 

References:  1.2,  1.12,  1.16.  1.21,  3.5,  5.11,  5.16 
|  End  Selection  Rule  | 


Method  Ordering  Rules 


|  SelectionRule  RemoveRefl  | 

IF  a)  MegaMove  good  candidate 
THEN  MegaMove  >  PoeitionalMegaMove 
References:  1.2,  1.16,  3.2 

|  End  Selection  Rule  | 


n 


*e  *•  *• 

'Z«n.V  . 
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{  SelectionRule  RemoveRef2 

IF  a)  Ml | MepaMove  Is  candidate 

b)  M2 1  MagaMove  Is  good  candidats 

c)  component*of[Y  of  M2.  Y  of  Ml] 

THEN  Ml  >  M2 

[Usually  battar  to  taka  as  much  context  with  you  as  possible.] 
References:  1.2,  1.12,  1.10 
I  End  Selection  Rule 


|  SelectionRule  RemoveRef3 

IF  a)  Ml  |  PositionalMegaMove  is  candidate 

b)  M2 1 PositionalMegaMove  Is  candidate 

c)  component-of[Y  of  M2.  Y  of  Ml] 

THEN  Ml  >  M2 

[Usually  battar  to  taka  as  much  contaxt  with  you  as  possible  ] 
References :  1.2,  1.12,  1.18 
|  End  Selection  Rule 


|  SelectionRule  RemoveRefd  | 

IF  a)  RemoveByObjectlzIngContext  is  a  good  candidate 
THEN  RemoveByObjectizingContext  >  (MagaMove,  PositionalMegaMove) 
References:  1.19 

I  End  Selection  Rule  I 


|  SelectionRule  RemoveRefS 

IF  a)  BabyWIthBathWater  is  a  good  candidate 
THEN  BabyWithBatbWater  >  (MagaMove,  PositionalMegaMove) 
I  End  Selection  Rule 


G.14  Remove 
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|  SelectionRule  RemoveRef6  | 

IF  •)  ReplaceRefWithValue  Is  a  good  candldata 
THEN  ReplaceRefWithValue  >  (MagaMova.  PosItlonalMegeMove) 
References:  2.2 

|  End  Selection  Rule  | 


|  SelectionRule  RemActl  | 

IF  a)  RemoveUnusedActlon  Is  a  good  candidate 
THEN  ReffloveUnuscdActlon  >  RemoveF romDamon 

[It's  worth  a  try.] 

References :  5.11,  6 . 15 

|  End  Selection  Rule  | 


G.1 5.  Show 

ShowNoChange  (4.16) 


ConjunctlmpliesConjunctArm  (4.2) 


|  SelectionRule  *ConjunctImpl lesConjunctArml  | 

IF  a)  ConjunctlmpliesConjunctArm  Is  a  candidate 

b)  Supergoal  Is  Map  C\prohibltive-constreint 

c)  The  conjunct  arm  A  Is  a  good  predictor 
THEN  ♦ 2 

References:  4.2 

|  End  Selection  Rule  | 
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SalactionRula  •Conjonctlmpl  1esConjunctArm2  | 

IF  a)  Conjunct  Imp  1  lasConjunctArm  Is  a  candidate 

b)  Supergoal  Is  Map  C\prohlbitiva-conatraint 

c)  Tha  conjunct  arm  A  Is  a  bad  predictor 
THEN  -2 

[a.g.  A  Is  bad  tl  It  acts  as  Idiot  light:  tails  you  whan  somathlng  Is  wrong,  but  no  way  to 
backtrack  and  maka  It  right.} 

Aalarancas:  4.2 

End  Salaction  Rule  | 


ShowOyateleologicaf  (1.22, 2.14,  3.6) 


|  SalaclionRula  •ShowDysteleologlcal 

IF  a)  ShowDysteleologlcal  is  a  candldata 
THEN  +2 

Aalarancas.  1.22,  2  14.  3.6 
I  End  Salaction  Rula 


ShowUpdateGiveaValue  (2.3) 


|  SalactionRula  •ShowilpdateGivesValue 

IF  a)  ShowUpdateGivesValue  Is  a  candidate 
THEN  ♦ 2 
Aalarancas:  2.3 
|  End  Salaction  Rula 


ShowNawVaiuaStiltValid  (2.4) 


|  SalactionRula  •ShowNewValueStlllVal id 

IF  a)  ShowNewValueStlllVal Id  Is  a  candidate 
THEN  *2 
Aalarancas:  2.4 
I  End  Salaction  Rule 


3 


MovalntarvaningUpdata  (2.5) 


"  .'.•‘il  .W  ;SL 


G.15  Show 


|  SelectionRule  •MovalntarvanlngUpdata 

IF  a)  MovelntervenlngUpdate  Is  a  candidate 
THEN  *2 
References:  2.S 
|  End  Selection  Rule 


Method  Ordering  Rules 


|  SelectionRule  ShowVall 

IF  a)  Ml  |  • ShowilpdeleOivesVelue 

b )  M2 1  ’ShowUpdeteGivesVelue 

c)  Ml  computationally  closer  to  It  than  M2 
THEN  Ml  >  M2 

|  End  Selection  Rule 


r-j 

G.16.  Simplify 

1 

No  rules. 

S 

G.1 7.  Swap 

SwapStatements  (2.9) 

|  SelectionRule  *SwapStatement$ 

IF  a)  SwapStatements  is  a  candldata 
THEN  *5 
References :  2 . 9 
|  End  Selection  Rule 
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G.18.  Unfold 

ScatterComputationOfDerivedRelation  (3.19,  4.18,  5.6,  5.9, 5.10,  6.19) 


|  SalactionRule  •ScatterComputatlonOfDerlvedRelatlon  | 

IF  a)  ScatterComputatlonOfDerlvedRelatlon  Is  a  candldata 
THEN  +6 

References:  3.19,  4.18,  6.8.  5.6.  6.10,  6.16 
|  End  Salaction  Rule  I 


ScatterComputationOf Demon  (6.4,  6.20) 


|  SalactionRule  •ScatterComputatlonOf Demon  | 

IF  a)  ScattarComputatlonOfDamon  Is  a  candldata 
THEN  +5 

Reter»nc»s :  6.4,  6.20 

|  End  Salaction  Rula  | 


Unfold  Atomic  (2.7, 5.1 3, 5.1 6) 


|  SalactionRule  *UnfoldAtom1c  I 

IF  a)  UnfoldAtomfc  Is  a  candidate 
THEN  ♦ 5 

References:  2.7,  6.13,  5.16 

|  End  Salaction  Rula  | 


UnfoldSimpKSB  (TextPreprocaasor) 


G.19.  Problem  Solving  Resource  Rules 


G.19  Problem  Solving  Resource  Rules 


PAGE 


|  SelectionRule  ReformUnnecessary  | 

IF  a)  M  |  mat  hod  Is  candidate 

b)  M  contains  a  reformulate  action  A 

c)  A  Is  achlavad  trivially 
THEN  +1 

References:  1.11.  1.14,  1.16,  1.18.  1.20,  4.8,  4.8.  4.11.  4.14, 

4.16.  6.2 

|  End  Selection  Rule  | 


|  SalactionRula  RequIreReformUnnecessary  | 

IF  a)  Goal  Is  { Map.Casify }  R | require 

b)  M\ method  Is  candidate 

c)  M  contains  a  reformulate  action  A 

d)  A  is  achieved  trivially 
THEN  +1 

[Give  a  bonus  to  methods  which  don't  need  to  reformulate  a  require  statement.] 
References:  4.8.  4.8,  4.11,  4.14,  4.16 

|  End  Selection  Rule  | 


|  SelectionRule  EquivUnnecessary  | 

IF  a)  M | method  Is  candidate 

b)  M  contains  an  equivalence  action  A 

c)  A  Is  achieved  trivially 
THEN  +1 

|  End  Selection  Rule  | 


|  SelectionRule  ReadyToGo  | 

IF  a)  H | method  Is  candidate 

b)  forall  actions  A  of  M  either  1)  A  Is  an  Apply, 
or  2)  A  Is  achieved  trivially 

THEN  4i 

[It  only  apply  goals  left  then  cheap  choice] 

References:  1.11.  1.16.  1.17,  1.22,  2.6.  4.8,  4.8.  4.11,  4.14.  6.6 
|  End  Selection  Rule  | 
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|  SelectionRule  *ShowUnnecessary  | 

IF  a)  K | method  Is  candidate 

b)  H  contains  a  Show  action  A 

c)  A  Is  achieved  trivially 
THEN  +1 

|  End  Selection  Rule  | 


|  SelectionRule  BurnedOutHulk 

IF  a)  Goal  Is  Remove  X  from  spec 

b)  X  is  a  defined  strucutre 

c)  Method  M  removes  the  need  for  X 
THEN  +2 

References:  1.1,  2.1,  3.1 
|  End  Selection  Rule 


|  SelectionRule  Fill  In 

IF  a)  Goal  Is  Remove  RR |  relation-reference  from  spec 
THEN  Try  filling  In  values  within  RR's  context 
References:  1.2,  1.12,  1.19,  2.2,  3.2 
I  End  Selection  Rule 


SelectionRule  MapSubOfRemovel  I 

IF  a)  Goal/Supergoal  G  Is  Map  X 

b)  Supergoal  of  G  Is  Remove  X  from  spec 
THEN  +1 

[A  method  which  keeps  X  localized  facilitates  the  higher  level  of  goal  of  removing  X.] 
References:  1.10,  1.11 

End  Selection  Rule  I 


G.20  General  Rules 
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|  SelectionRule  MapSub0fRemove2  | 

IF  a)  Goal/SupargoaT  G  la  Map  X 

b)  Supergoal  of  G  Is  Remove  X  from  spa c 
THEN  -2 

[A  method  which  spreeds  X  out  when  trying  to  remove  It  Is  counterproductive.] 
References:  1.11 

|  End  Salsction  Ruls  I 


|  SelectionRule  DamonsAraGood  | 

IF  a)  Goal /Supergoal  Is  Map  X 

b)  Method  M  changes  X  to  a  demon 
THEN  +1 

/ Demons  ere  generally  easy  to  work  with.] 

References:  1.11.  4.1,  5.2 

|  End  Selection  Rule  | 


|  SelectionRule  Subcomponent  I 

IF  a)  Goal  is  Reformulate  X  as  P 

b)  pattern-match[Y,  P.  X] 

c)  Method  M  extracts  V  from  X 
THEN  42 

|  End  Selection  Rule  I 


|  SelectionRule  ReformAsExtreme  I 

IF  a)  Goal  Is  Reformulate  R| relative-retrieval  as  X ■  P | positional-retrieval 
b)  Method  M  reforms  R  as  extreme 
THEN  41 
References:  1.14 

|  End  Selection  Rule  | 


PAGE  464 


SELECTION  CATALOG 


|  SalectionRula  UseConjunctArm 

IF  a)  Goal  Is  Show  X I  conjunction  Inpl  las  i  \  unbound 

b)  Supargoal  is  Map  C | prohibitive-constraint 

c)  Method  M  binds  V  to  arm  of  X 
THEN  *2 

Rate  ranees :  4.2 
|  End  Salaction  Pula 


|  SalectionRula  CasIfyComplaxConstruct 
IF  a)  Goal  is  Map  X 

b)  X  is  complex 

c)  Mathod  M  splits  X  into  simpler  cases 
THEN  +2 

References:  4.4,  4.7.  4.9.  4.10,  4.12.  4.13,  4.15,  4.16.  6.1 
|  End  Salaction  Rule 


SalectionRula  CheapRemove 
IF  a)  Goal  Is  Remove 

b)  M |  method  Is  candidate 

c)  forall  actions  A  of  M  either  1)  A  Is  an  Apply. 

or  2)  A  is  achieved  trivially 


[If  you  can  gat  rid  ol  something  cheaply,  do  It.] 
|  End  Selection  Rule 


